Now that we have wget

[NAS]

The unRAID addons are great buy way way to complicated for many users. The wiki helps alot but its no trivial undertaking to read all the forums posts re: things like unMENU and BubbaRAID etc

 

Now that 4.4.x has wget included is there scope to save users alot of learning and just grab and install directly?

 

This conversation may be too early in the development of any or all of the tools but its probably one worth having.

[Joe L.]

The unRAID addons are great buy way way to complicated for many users. The wiki helps alot but its no trivial undertaking to read all the forums posts re: things like unMENU and BubbaRAID etc

 

Now that 4.4.x has wget included is there scope to save users alot of learning and just grab and install directly?

 

This conversation may be too early in the development of any or all of the tools but its probably one worth having.

User's can use wget, in the same way they could download to their PC and then move a file to the flash drive to install it.  It is the same "url"

Unfortunately,  at least in my opinion, for the less technical, it is far more complicated than most will be able to manage.

 

Using "wget" the user must know:

• how to log onto the unRAID server via telnet
  
• the correct URL to request via "wget"
  
• how to install what they have gotten
  
• how to configure what they have installed
  
• how to run what they have installed
  
• how to re-install upon reboot
  

 

To download to their PC they must know

• The URL to click on
  
• How to move the downloaded package to their flash drive
  
• how to install what they have gotten
  
• how to configure what they have installed
  
• how to run what they have installed
  
• how to re-install upon reboot
  

 

Certainly, the wiki can be expanded to put detailed instructions.  But the instructions might as well be written in "Greek" for many.  Something as simple as "log onto the server using 'telnet'" is far more complicated than many can handle without a lot of hand holding.

 

Most windows users can handle "download, unzip, add this line to the end of the config/go file" but even that might be difficult for some who have not yet enabled their windows explorer to show hidden and system files.

 

All that considered, "wget" makes it easier for the experienced user, but does not do anywhere near asmuch for the inexperienced.

 

As far as I've seen so far, the pre-packaged "BubbaRAID" and the unMENU packages have been the easiest ways for many to add features to their server.  It takes far less knowledge to simply click on a button.

 

Perhaps an "Add-Ons for beginners" section might be added to the wiki...  I'd suggest a thread here in the User-Customizations forum, but it would probably end up as long as some of the others you mentioned.  The wiki is probably far easier to manage.

 

Nothing will really change unless Tom adds package management to his base product, and I don't see that happening any time soon, if at all.  Too many support issues.

 

Until then, I think the wiki "Add-Ons for beginners" section might be a strong possibility.  (Now all that has to happen is it get written)

 

Joe L.

[bubbaQ]

I have to concur that adding package management to unRAID would likely escalate support issues exponentially, far in excess of the revenue stream generated.

 

There are some fantastic additions out there (both utilities for unRAID itself and stand-alone applications so an unRAID server can do multiple things). 

 

However most of them take much too much effort and expertise to install and configure.  There are better ways to handle addons.

 

Take for example, this forum software from Simple Machines.  Free and open source.  There are literally hundreds of plugins, and for most, no one has to edit a config file.  Installing one of them is as easy as clicking on an "install" button.

 

While a lot can be done with awk, using it to write dynamic html is downright painful.  It lacks some basic constructs, such as the "case" statement.  The code is much less readable than any other form of dynamic html generating platform I have ever used!  But, it is all we have.

 

With no disrespect (indeed, great admiration) to the folks that have done addons in awk (as I have, albeit not as extensive as others), if there was ever an official "hook" in unRAID for user-contributed addons, it would much better be done via a web server and php.

 

Including a small web server (like lighttpd) and php on the stock unRAID distro, adding plugins to unRAID could be done in a very user-friendly interface and with a single click.  Management and configuration of those plugins could be the same way.

 

This is ripe for the "portal" concept.  What I would like, is the option in unRAID to enable an applications portal.  If you don't enable it, unRAID is unchanged.  If you do enable it, then emhttp boots on a different port, and the web server launches on port 80 at boot time.  The web server home is a portal, with a condensed, simplified display of unRAID status, and a link to the full emhttp interface.  The portal home would scan a "plugins" directory for subdirectories, and display a link to the appropriate portal page for that app in that app's directory.

 

I know there are details I haven't mentioned, but that's the concept I have, if Tom is ever considering adding "hooks" for plugins.

[SSD]

I think that the design point for most addons here has been a user with some general technical computer skills, but perhaps few, if any, Linux skills.  Also required is a willingness to invest a little effort in learning to be able to do more with their unRAID server.

 

I think that these targets have been realized with unmenu, BubbaRAID, and others.  The package manager has even made installing most anything , from addons (like PowerDown) to Slackware packages (like bwm-ng) very easy and automatic on each boot - all from a Web interface and without the slightest idea of how Linux does it behind the scenes.

 

BubbaRAID is a bit more involved, buy hey, it is a whole new OS install!  I installed the 4.3 version and it was virtually painless - and I have zero experience with installing / configuring Linux.  (I am waiting patiently for a 4.4 version that can happen all in one step).

 

Even if someone felt installing something was somewhat complicated, the level of handholding and responsiveness here is incredible.  No one that wants to install something wants for help.

 

I'd rather see us continue to focus on our target audience, and expand the functionality to provide better tools and protection to users (including ourselves) interested in unRAID addons, rather than trying to make the existing functionality easier to access for a very small (perhaps zero) population that has remained silent, either becuase they think it is too hard or just not worth their effort.

 

Just my $0.02 worth.

[jimwhite]

I agree with that 100%...

 

[WeeboTech]

ncluding a small web server (like lighttpd) and php on the stock unRAID distro, adding plugins to unRAID could be done in a very user-friendly interface and with a single click.  Management and configuration of those plugins could be the same way.

 

This is ripe for the "portal" concept.  What I would like, is the option in unRAID to enable an applications portal.  If you don't enable it, unRAID is unchanged.  If you do enable it, then emhttp boots on a different port, and the web server launches on port 80 at boot time.  The web server home is a portal, with a condensed, simplified display of unRAID status, and a link to the full emhttp interface.  The portal home would scan a "plugins" directory for subdirectories, and display a link to the appropriate portal page for that app in that app's directory.

 

I know there are details I haven't mentioned, but that's the concept I have, if Tom is ever considering adding "hooks" for plugins.

 

I really think this is good way to go.

 

[bubbaQ]

Tom mentioned in another thread that he was considering exposing more commands from the unRAID management core.  That would also greatly benefit addons, particularly a web based portal since with a simple SSI or php include, you can imbed a mini-dashboard of unRAID status on every page in the portal or in the pages of the addins.

 

On a related note, one other thing that addons present - path guidance for future built-in features.

 

For example, radios used to be options you had to add to a car.  Now they are standard, but due in large part to widespread acceptance and then desire (there was a lot of resistence to radios in cars in the beginning --both technical, psychological, and safety).  Out of the current crop of unRAID addons should come some future built-ins, such as unraid_notify, scheduled parity checks, PM in the form of smartctl tests.

 

BubbaRaid is really not an addon for unRAID.  It is more a platform for applications that are unrelated to unRAID, but can live on the same box.  Other than some kernel changes (such as pc_speaker, cpu frequency scaling, hardware monitoring, etc.) there isn't much in BubbaRaid (currently) that would be candidates for unRAID stock.

[NAS]

 

I'd rather see us continue to focus on our target audience, and expand the functionality to provide better tools and protection to users (including ourselves) interested in unRAID addons, rather than trying to make the existing functionality easier to access for a very small (perhaps zero) population that has remained silent, either becuase they think it is too hard or just not worth their effort.

 

If i read what your saying right then I respectfully disagree. Our target audience should be unraid users, all of them. Sure there will be hacks that will be beyond the majority of the userbase but IMO the only thing that gets in the way this now is the sheer volume of words and threads on the install. Its overly daunting for most.

 

i also like the idea of a web sever that users develop on bolt-ons for (in a similar fashion to unMenu). The difference would be in a perfect world the base web server and simple packages could be on the main official distro and users add to that base (as opposed to the community working on the base and also the addons).

 

I dont see any reason we could do some dev work on this here as a community first. Getting a popular webserver like lighthttp working shouldn't be overly hard.

 

 

[Joe L.]

ncluding a small web server (like lighttpd) and php on the stock unRAID distro, adding plugins to unRAID could be done in a very user-friendly interface and with a single click.  Management and configuration of those plugins could be the same way.

 

This is ripe for the "portal" concept.  What I would like, is the option in unRAID to enable an applications portal.  If you don't enable it, unRAID is unchanged.  If you do enable it, then emhttp boots on a different port, and the web server launches on port 80 at boot time.  The web server home is a portal, with a condensed, simplified display of unRAID status, and a link to the full emhttp interface.  The portal home would scan a "plugins" directory for subdirectories, and display a link to the appropriate portal page for that app in that app's directory.

 

I know there are details I haven't mentioned, but that's the concept I have, if Tom is ever considering adding "hooks" for plugins.

 

I really think this is good way to go.

 

You will not get any complaints from me if Tom adds a general purpose web-server.  It might take me a day or so to write a php equivalent to unnenu.awk that can use the existing plug-ins, and then it could evolve from there.  Problem is, I don't see it happening in the near future.  Tom has enough "basic" functionality he needs to focus on first.  (NFS, e-mail alerts, UPS support, SMART reporting, SAMBA/CIFS support, array and network performance, space allocation in user-shares, new chip-sets, etc) 

 

You are right, getting a web-server installed and running would probably not be too hard, but there is the chicken-and-egg issue... Most people would not have a clue how to install, configure, and manage a web-server.  A LOT of hand-holding would be critical to any effort.

 

Instead, I used a utilities that are shipped with unRAID (humble "awk" and "shell").  By using them it means a user can indeed unzip them, add one line in notepad to config/go, and be up and running.  Far more limiting, but far easier for most.    I myself have been impressed what we have collectively been able to do with such humble tools.    I would love a built-in web-server. Lightweight-or otherwise.

 

It would have been easier with such an environment... and we might get it some day, but for now we can use what we have, build what we don't, and manage our servers to protect our data. (core functionality)

 

I miss the "case" construct in "awk" too, but it is certainly not a show stopper.  Odds are I can write a useful program or two without it.      The unmenu plug-ins can be easily written in anything you like.  The only constraint is that the file have a series of newline delimited strings it can parse for the "label" and "url"  One existing plug-in I created was written using "shell"  It just comes down to using the tools creatively.  If you are comfortable using "php" then go for it.

 

Joe L.

[NAS]

Playing devils advocate....

 

i cant see Tom ever including unMenu in his commercial product as it based on awk. It is however easier to imagine him including the base components for a more traditional approach based on say lighty with php especially if the community has fleshed it out before hand.

 

Developing based on whats available is a noble endeavour and i can see the logic/merit in it but there is mileage in developing based on a traditional platform as well as it has a much higher probabilty of making the jump from community hack to official distribution.

 

Tom focuses on stability for unRAID but adding a web server and moving emHTTP to a differernt port but not including all the custom plugins fits with the stability model but also makes it easy for the community to cater for their own needs.

[bubbaQ]

It would have been easier with such an environment... and we might get it some day, but for now we can use what we have,

 

I agree.  The gist of my post (and the title of this thread) was that Tom listened to suggestions and added something that had widespread usefulness, and particularly for addins (wget).  If he is still in a generous mood to throw a bone to the addin developers I was pointing out that a web server would be the logical next step to add to the stock unRAID distro from the standpoint of enabling more user (and developer) friendly addins.

 

Certainly things like e-mail notification and SMART reporting are a MUCH higher priority to add to the stock unRAID distro.  I don't know how hard it is for Tom to add screens and generate dynamic HTML in his emhttp code and process posted form variables.  If it is simple, he can add a screen to emhttp  for configuring the variables used by an e-mail notification system (recepients, SMTP servers, logins, frequency, parameters to monitor, thresholds, etc).  

 

As an alternative, if he added a web server and PHP, developers in this forum can take it from there.

 

This was definitely *not* intended as any type of dissing of awk or the awk addins.  It's like I pointed out before with Bogart dealing with the bent prop shaft in the middle of the jungle in the African Queen.  He made do (and succeeded) with what he had.  But it would have been MUCH easier had someone air-lifted him a forge and tools.

 

Right now, the general paradigm of addons is to map a drive to the flash, copy some files, edit the go script, edit some config files, etc.... all things that CAN be done 100% from Windows.  I remember a telling post from a user "I don't want to see Linux."  We do have lots of those folks using unRAID.

 

Another way to do it is now opened up by having wget in the stock distro.. that takes only 2 simple steps (that can be all in the same command line):

 

1) wget a script from a web site

2) run script.

 

The script can do the prompting and hand-holding through asking the user questions, such as the unraid_upgrade script does.  That, to me, is a significant improvement since the part of the previous paradigm that seems to cause the most support here is editing the config files, and saving stuff in the right location (and not saving with DOS CR/LF).

 

With unRAID 4.4 and above, a user can cut and paste this command into a terminal window:

 

 

wget http://www.tcpatools.com/bubba/unraid-upgrade.awk; awk -f unraid-upgrade.awk

 

to download and run the unraid-upgrade script.

 

If a web server and php were added to the stock distro, another new paradigm is made possible that is even simpler and more customizable.

[WeeboTech]

Tom focuses on stability for unRAID but adding a web server and moving emHTTP to a differernt port but not including all the custom plugins fits with the stability model but also makes it easy for the community to cater for their own needs.

 

I'm in agreement here. If a basic index.cgi or index.php could redirect to the new emhttp port allowing custom plugins to replace this page on demand.

It would make a nice simple way of providing the best of both.

 

However, we have plenty of talented people. I'm sure we could develop a slackware package that could.

1. Check for the existence of necessary packages.

2. Download if not available.

3. Install packages and custom index.php if available.

4. Make all the automated changes needed in the go script to run this install first and then execute emhttp on a different port.

 

Once this piece is done, a new modern unmenu.php could be used to replace the initial redirecting index.php page.

Anything is possible as a slackware package is just a tar with an install script that is executed after the package is installed.

 

[bubbaQ]

Considering stability first, I think leaving emhttp on its home port of 80 is probably the safest.  If it moves, and the web server has a problem, a novice would be hard pressed to get back to the unRAID interface.  The addins portal needsto be on a port other than 80... let's use port 87 as an example.

 

Here's my idea.  I noticed when you got to //tower or the server IP, you get redirected to //tower/main.htm

 

That could be the hook -- instead of forwarding to main.htm, the default "//tower" could give you a simpler unRAID status display and an  option to go to the full unRAID management interface (i.e. main.htm) or to the addins portal.

 

If the addins portal is not enabled by the user, then the current auto-forwarding to main.htm will proceed as it does now.

 

This new default "home" page for emhttp could be a simple as a frameset.  In the standard unRAID management interface, the user would enter a field for the url of the home page for the addin portal.... such as //tower:87/portal.php.  Tom would have to create an html page in emhttp for unRAID status (call it status.htm) with quick status/health info of the server and a link to the full management page (main.htm).  Then create a frameset with status.htm on the left, and the user-entered portal url on the right (//tower:87/portal.php).

 

Worst case when it all blows up on the addins side, you get a 404 error in one frame.... but the unRAID pane is good as long as emhttp is up.  Emhttp could also do it w/o a frame, and wget the url (//tower:87/portal.php) and echo it in with the emhttp "home" page, and even check the status and make a user-friendly error message if the url (//tower:87/portal.php) died.

 

If the url field is empty, the the emhttp "home" (//tower/) just does the same forwarding to //tower/main.htm that it does now.

[SSD]

If Tom creates a mechanism and even tacit approval for allowing addons to the Web GUI, I'd certainly be willing to port and enhance myMain for PHP, Perl or whatever.

 

My biggest issue with AWK is that it can only service one request at a time without crashing.  This prevents serving graphics to the pages, and crashes unmenu if you happen to click on a link twice (hence the need to run it in a loop from the command line).  As a development language, however, I found it quite usable for the myMain plugin.  The lack of a "case" statement was not an issue for me.  I might have liked a few more built-in string manipulation funcitons.  (You really are forced to use regex for just about everything!)

[bubbaQ]

I initially felt the same about regexp and strings, and ended up writing a few stock functions I just included everywhere.  Then a lot of string functions were added in 4.x.  As of 5.x, it has everything I need.

 

   http://us2.php.net/manual/en/ref.strings.php

 

The reason I mentioned the case statement in particular is where you (potentially) have multiple developers looking at and contributing to the same codebase, ease of reading and comprehending the logic of someone else's code is a priority.  Of course anyone can write spaghetti code in any language, but if you do try to write code so it is comprehendable by other devs, the case statement is often useful over nested ifs.  This is doubly-important when you are writing code to generate code in another language (in this case, html).