Updated list of issues from this tread:

 

Webserver-specific issues

• No webserver access log or error log
  
• $_GET global not populated
  
• $_SERVER global missing standard elements (e.g. DOCUMENT_ROOT)
  
• No access to mime.types
  
• Includes using relative paths don't work
  
• Can't stream media over http
  
• SSI support
  
• CGI support
  
• SCGI support
  

 

PHP issues

• XML-RPC
  
• pcre
  

 

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

Original OP

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

I am very excited about the new 5.0 and looking forward to filling it out.

 

But I am disappointed about one thing -- that there is no real web server.

 

I understand the benefits of having emhttp handle the web gui and process the submits to configure/manage the array, and populate the php vars for plugins to access.  That integrates well, and I would not suggest changing it.

 

But one of the first things I noted after I started digging, is that a lot of stuff I wanted to do I could not.  You can't really run php directly... you can only run it in a limited way via emhttp and the plugin architecture.  That works fine for small utility plugins, but it will not work for many other things.

 

My first response to that was we need a way to get "raw" output from emhttp running plugin php code, but I realize even that will not allow things like ajax explorer or the nzbget web interface, and other real php applications.

 

I believe the only way to fully realize the potential of community development on unRAID is with a real webserver.  I don't mean have the webserver process any of the array management code -- that can and should go through the emhttp web interface.

 

So just to test, I applied unraid-Web to the new 5,.0, and it worked fine, with just one small change to the php.ini file, and I posted the new (1.05) unraid-Web for download.  I intend to migrate several things to the new 5.0 plugin architecture.

 

But much of what I want to do (some of it had a first-generation incarnation in unraid-Web and BubbaRaid) it is not migrate-able, as it needs a real webserver.

 

I like Lighttpd.  It's simple, small, light, and fast.  It can be installed on unRAID from a simple package and script without any user configuration, and work right out of the box.  I would have loved to see it in stock unRAID.

 

If others are interested in having a long-term stable and standard's based install of Lighttpd on unRAID, we can collaborate on standards and go for it and I'll make a commitment to long-term support and hosting it.

 

Or if Tom is intending to do something along the lines of a full webserver like Lighttpd in the stock unRAID distro, then I'll table this idea.

 

Comments?

I'm glad you mentioned this.

In days gone past, I too thought unRAID needed a http server capable of external functionality.

It started when I was exploring rtorrent, xml-rpc and some form of browser management.

 

I did not continue too much further because there was communication in regards to new management and plugin capability.

 

What I did play with was a very small http server core in C and modified it to have the most basic perl interpreter embedded in it.  I was going down the path of engineering my own front end and management system.

 

The new environment looks nice, but I think we have to sit with it more to see how it can be extended or plugged in.

 

I thought the unraid-web project was a great start.

I had hoped the new 5.0 would have some form of external hook api so other programs could call it, rather then it calling other programs.

 

Before I comment either way, I would like to learn and understand what's missing and is it even feasible for emhttp to have it.

 

I know the whole sock/xmlrpc comes into play with rtorrent.

What else is there?

 

I'm all for lighthttpd, it was on my Kuro box, it was on my Thecus, ReadyNAS used apache, but the later revs were really doggedly slow. (eh, it was slow on my kuro box too).

 

I would still like to learn what interfaces are missing before I say, "yeah go do that, emhttp is not the place to do it."

 

If you do decide to go with unRAID-web. I would help support it to, simply because I thought it was a good way to go.

 

emhttp is a good interface for the base unRAID product.

 

At this point in time, I'm not knowledgeable enough to say, we need a more advanced http server.

If there is no way to add XMLRPC to emhttp then I may lean towards the more advanced http server.

 

I am still interested in writing my own XML-RPC control daemon for unRAID.

I don't know that I could do this without an XMLRPC capable http server.

 

I'm still "thinking out loud" on how we can manage system plugin start/stop.

(spent the eve looking at log scrapers and clustering tools... ma mind be spinnin...)

 

I think it would be rather handy honestly. I don't care if it displays basic html and nothing fancy. Sometimes it just helps to serve up a page or some files for those odd rare occasions.

 

Start adding in more functionality and its just gravy.

emhttp will launch call a php file directly if it has a php extension.

 

For example,

 

http://tower/myfile.php

 

Server will look for 'myfile.php' in the /usr/local/webGui directory, and if found execute:

 

/usr/bin/php /usr/local/webGui/myfile.php <querystring>

 

where <querystring> is simply the query string passed from original request.

 

 

Edit: I should add... what emhttp does is this.  If given a filename without an extension, it looks for 'filename.page' in /usr/local/webGui.  If found, then it invokes php like this:

 

/usr/bin/php /usr/local/webGui/template.php /usr/local/webGui/filename <querystring>

 

In addition, prior to invoking /usr/bin/php, emhttp will also do a 'get_status()' operation, which updates and dumps the complete set of md/emhttp status to the /var/local/emhttp/*.ini files.

 

Well sure enuf it will. 

 

I tried that earlier and all I got was a blank screen and gave up, but when I went back, I see the permission were hosed on the file I tried the test with.

 

Problem is that's not a place that it is easy to put persistent code..... perhaps create a subdir in webGui as a symlink to a web root the flash for example.

 

I'll figure something out.... you pointed me in the right direction.  Don't know if it will solve the issue with rtorrent xmlproc.

Problem is that's not a place that it is easy to put persistent code..... perhaps create a subdir in webGui as a symlink to a web root the flash for example.

 

Yes, I intend to add additional path lookups, as part of the plugin architecture.

I have it working, so

 

http://tower/Utils/MdCmd.php?cmd=status

 

Will run the php code like a regular web server.  But that way, there is no access to the php vars related to the array/server status.

 

Is there possibly some include we can add to our php code that would provide those arrays?  Never mind  I found them:

 

// Read emhttp status
$var = parse_ini_file( "/var/local/emhttp/var.ini");
$sec = parse_ini_file( "/var/local/emhttp/sec.ini", TRUE);
$devs = parse_ini_file( "/var/local/emhttp/devs.ini", TRUE);
$disks = parse_ini_file( "/var/local/emhttp/disks.ini", TRUE);
$users = parse_ini_file( "/var/local/emhttp/users.ini", TRUE);
$shares = parse_ini_file( "/var/local/emhttp/shares.ini", TRUE);

 

Also it seems $_GET is not avaialble.... I tried print_r($_GET) and it shows it as an array, but no contents.

 

The $_SERVER global is there, however, and the get variables are in the argv array.

 

phpinfo also shows the _GET array is missing.

I should point out that I haven't fiddled with the PHP install at all, in fact I think there's not even a php.ini file.  I just got it installed and working good enough to get -beta1 out.  A lot of the work was in "translating" the web pages from my own internal template implementation to PHP.  So the webGui pages are probably not how I would have implemented from scratch, but does the job.

No problem.  The missing $_GET array is puzzling, but not a show stopper.

 

I much prefer a RAD development cycle, of getting something out there for as many eyes as possible to look at. 

Although there is a workaround for the lack of $_GET globals, I keep running into all kinds of problems with a lot of things even marginally sophisticated with the emhttp web server functionality.  

 

No XML-RPC or RPC-API

 

Can't stream media via http.

 

No access to mime.types

 

This makes web interfaces to things like rtorrent very difficult if not impossible, and these are apps that currently I have living on the same server with unRAID.

 

I don't know if these are just configuration issues that could be resolved or not.  But unless it is a config issue and the web server features of emhttp can be fleshed out, I think for a lot of potential applications to run on unRAID, a real web server is going to have to be used.

I'm in need of basic CGI in order to install NAGIOS and use it's included tools.

I know there is an scgi.c out there. I have it locally here.

It's actually a cgi-bin application that then does small cgi.

 

Do you think this would work for rtorrent if it was supported?

Perhaps this is bigger then emhttp should support?

No XML-RPC

 

I think there is a way to compile it into php.

I did get it to compile, but got side tracked before testing it out.

In any case, it would require the support libs to be installed in the base unraid or php would need to be upgraded along with the support libs in one fell swoop.

In any case, it would require the support libs to be installed in the base unraid or php would need to be upgraded along with the support libs in one fell swoop.

 

Yes, I guess I though it was implied, but am also including the necessary libs to provide a robust php environment too.... the robust webserver isn't worth much unless the php is robust as well.

 

Think unraidWeb w/o the packages and package manager.

Actually, having lighttpd along side the existing features of emhttp in unRAID 5.0 have a synergy.  emhttp provides a door to simple php, that can be used to do some behind the scenes stuff to manage lighttpd itself.... for example, restarting a web server from php launched by the webserver itself is fraught with peril.  That is why I had a small awk listener and the lighttpd.angel process.  Now that functionality can just use emhttp.

Actually, having lighttpd along side the existing features of emhttp in unRAID 5.0 have a synergy.  emhttp provides a door to simple php, that can be used to do some behind the scenes stuff to manage lighttpd itself.... for example, restarting a web server from php launched by the webserver itself is fraught with peril.  That is why I had a small awk listener and the lighttpd.angel process.  Now that functionality can just use emhttp.

And lighttpd is very light-weight in its memory usage.  It could easily have a place.

I'm looking forward to it.

Even the full unraidWeb package, when added to 5.0, only consumes 70Mb more than stock 5.0 (both RAM for the files stored on the root ramdisk, plus memory in use by lighttpd itself... and that was a compelte php install.

 

- lighttpd 1.4.19

- php 5.2.8

- Gamin 0.1.9 (FAM)

- libXML2 2.6.32

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

 

Before

Mem:   1024308k total,   180560k used,   843748k free,      288k buffers

 

After

Mem:   1024308k total,   248312k used,   775996k free,     1844k buffers

 

lighttpd config is in:  /boot/custom/lighttpd  

php config is in:  /boot/custom/php    (symlinked from /etc/httpd)

 

 

How do we handle possible collisions with PHP.

 

Should we have Tom upgrade to the most current, then stick with that for unRAID web, only updating the configure lines for needed libs in the slackbuild?

 

The two versions need to match if unraidWeb is going to add more support in the php system.

Almost everything is disabled in the base unRAID php environment.

The two versions need to match if unraidWeb is going to add more support in the php system.

 

Not exactly.... but I can handle it.  I have a working package doing it already.

Another casualty that won't run on emhttp. .... http://phpsysinfo.sourceforge.net/

Another casualty that won't run on emhttp. .... http://phpsysinfo.sourceforge.net/

 

Glad you found out before me, I was going to test that.

So what happened that it won't run?

So what happened that it won't run?

 

Goes into some forwarding loop.  But I can't tell because ... wait for it... there is no http log or http.error log. 

After compiling in pcre and xml, I did get phpsysinfo 2.x to work.

I can't seem to get relative paths working for includes [sigh]

 

Also the $_SERVER global is missing a lot of stuff critical to good php code, like the root of the document webserver.  (DOCUMENT_ROOT is there, but it is empty (i.e. wrong).

_SERVER["CONSOLE"] => /dev/console
_SERVER["TERM"] => linux
_SERVER["prevlevel"] => N
_SERVER["INIT_VERSION"] => sysvinit-2.86
_SERVER["initrd"] => bzroot
_SERVER["PATH"] => /bin:/usr/bin:/sbin:/usr/sbin
_SERVER["runlevel"] => 3
_SERVER["RUNLEVEL"] => 3
_SERVER["_"] => /usr/bin/php
_SERVER["PWD"] => /
_SERVER["PREVLEVEL"] => N
_SERVER["SHLVL"] => 3
_SERVER["HOME"] => /
_SERVER["BOOT_IMAGE"] => bzimage
_SERVER["PHP_SELF"] => /usr/local/webGui/Pman.php
_SERVER["SCRIPT_NAME"] => /usr/local/webGui/Pman.php
_SERVER["SCRIPT_FILENAME"] => /usr/local/webGui/Pman.php
_SERVER["PATH_TRANSLATED"] => /usr/local/webGui/Pman.php
_SERVER["DOCUMENT_ROOT"] => 
_SERVER["REQUEST_TIME"] => 1279907474
_SERVER["argv"] => Array
(
   [0] => /usr/local/webGui/Pman.php
   [1] => 
)

_SERVER["argc"] => 2

I would suggest collecting requirements for Tom to adjust.

I've made my request for a real CGI interface.

It's important enough for me to request for Nagios.

That in itself is going to bring allot to the table for unRAID.

a real monitoring system!

 

For some of the other advanced tasks, we'll have to use a webserver.

emhttp does not seem to support posts. and I'm not sure I'll be able to get xmlrpc going.

This disappoints me as it could be a very standard published api for remote access/control to unRAID.

 

I had planned to go that route myself, but then thought it best to do it through emhttp.

But emhttp is not mature enough to handle this.