bonienl

Dynamix - Web GUI

Recommended Posts

WARNING: Do not use this version with unRAID OS v6.0

 

Dynamix webGui has been updated to version 2.2.10. Thanks to the support of the unRAID community a number of fixes and improvements are introduced. See below for a list of what has been changed, this includes changes in several optional plugins as well. All users of earlier versions are encouraged to upgrade to this version and use the updated optional plugins.

 

Starting from version 2.1.0 there is code alignment with the 64-bit version which is released separately.

 

Starting from version 2.2.1 the new dashboard page is included.

 

People using Plugin Control can update to the latest version from the GUI.

 

Introduction

Dynamix webGui is a dynamic webGui for unRAID systems with enhanced features and optional add-ons.

 

Dynamix is a spin-off of the original SimpleFeatures webGUI and is the next step in the evolution of the development of an enhanced webGui for unRAID systems. Its goal is to have pages dynamically updated and watch the operation of your unRAID server in real-time.

 

Dynamix webGui offers a number of improvements not available before:

  • Real-time page updates, the status view of your array is always up-to-date.
  • Tabbed viewing, more efficient use of the available screen area, scrolling is hardly required.
  • Improved visibility, better readibility and consistency of the sans-serif and monospace fonts in different browsers.
  • Improved operability, no more accidental cancellations or wrong button clicking.
  • Fully compatible with unRAID OS v5.0.

See the attachment for the new looks.

 

For more information and installation, visit Dynamix on github.

 

People familiar with the extra plugins (options) offered by SF, are happy to know that (most) extras are rewritten to work both with the new dynamic interface and unRAID OS v5.0 (including the latest version 5.0.6). In the process known bugs have been corrected and several improvements are in too.

 

Special attention has been given to those plugins (web-server & email-notifications) which require the installation of addition packages. I worked out an approach which hopefully will satisfy everybody. More details about this will be given in a separate topic.

 

I've put a lot of effort and time in this project to give you the best experience and offer a reliable and efficient solution. Meanwhile hop over to github and start your day in a fresh and dynamic environment  :)

 

Changes in 2.2.10

Added: DOWNLOAD button on syslog viewer page

Added: DONE button on various utils pages

Changed: smarter notifications system

Fixed: high load in cpu indicator on dashboard page

Fixed: minor css adjustments

Changes in 2.2.8

Added: page refresh timer indication

Added: notifications on critical disk issues

Added: notification when a new plugin version is available

Added: share list filtering based on global share settings

Fixed: corrections/improvements in notification system

Fixed: status and temperature display of unassigned devices

Updated: revised installation of Powerdown plugin

Changes in 2.2.7

Added: security and export settings in shares list

Added: hourly mover schedule

Added: page update timer option (real-time, regular, slow)

Fixed: display settings page

Fixed: share edit warning

Changes in 2.2.6

Added: number of active streams on dashboard

Added: additional views for network parameters on dashboard

Added: alternating text/image heat-alarm on dashboard

Fixed: minor css errors

Fixed: minor regression errors

Changes in 2.2.5

Fixed: wrong average speed calculation of parity check when longer than 1 day

Fixed: system information

Fixed: some regression errors

Changed: compressed display of CPU core speeds in dashboard

Changes in 2.2.4

Added: check validity of newly created user name

Added: check validity of newly created share name

Added: disk temperature threshold settings in Fahrenheit

Fixed: wrong iframe display (thanks to 'brutaldev')

Fixed: disk smartctl status check in dashboard

Changed: jquery v2.1.1 & jquery-ui v1.10.4

Changes in 2.2.3

Added: hot/max temperature settings

Fixed: text color in progress frame

Fixed: disk spun-down icon

Changes in 2.2.2

Fixed: improvements and corrections to dashboard page

Added: network info on dashboard page

Added: offline/maintenance mode indicator

Added: new powerdown utility, courtesy dlandon

Changed: ball icon colors

Changes in 2.2.1

Added: dashboard page

Added: black theme

Added: Mover button on Array Operation page

Changed: css coding

 

BonieNL

main-page.png.fa24e3283e50d54b029b0d3d2aece315.png

main-black.png.8301c2056a5bcd0f28932d4638bda485.png

Share this post


Link to post
Share on other sites

Looks very good bonienl will take it for a spin when get 5, great to see you back and about on the forums.

 

The Simplefeatures fan-boys will be wetting their collective panties when they see this, was getting tired of seeing simplefeatues this and simplefeatures that lol.

Share this post


Link to post
Share on other sites

SimpleFeatures isn't dead... I suppose speeding_ant is still working on the changes he has envisioned.

 

But I think a gap needed to be filled, it seems any development on the GUI side of things has stalled!

 

 

Share this post


Link to post
Share on other sites

SimpleFeatures isn't dead... I suppose speeding_ant is still working on the changes he has envisioned.

 

But I think a gap needed to be filled, it seems any development on the GUI side of things has stalled!

 

SimpleFeatures hasn't been touched for ages and has bugs, I congratulate you for bring this out looking on your github I see that you have s3 and email notify plugins for the GUI, a massive must in my book, thanks will install shortly :)

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

Share this post


Link to post
Share on other sites

Correct me if I'm wrong, but plugins don't require a reboot. 'installplg' installs it on a running system.  I've installed all my plugins without rebooting. 

 

Maybe I'm misunderstanding what you are trying to say.

Share this post


Link to post
Share on other sites

Hmm, it seems like most plg authors state that a reboot is required to install. Uninstall definitely requires it to flush the plugin out of memory since there is no universal plg "uninstaller".

 

I think you're right, dirtysanchez. Reboot isn't strictly required on install, but in this case it appears to be.

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

 

Share this post


Link to post
Share on other sites

I think most authors state that a reboot is required to install simply because it is easier from a novice's point of view and doesn't require them to use the cli.  That's just a guess on my part though. I don't see why ANY plugin would require a reboot to install, but then I'm no Linux guru. FWIW, while I haven't tried Dynamix yet, I used to run SimpleFeatures and I installed it without a reboot.

 

It definitely requires a reboot to uninstall though, like you said to flush it from memory. I'm sure it can be removed from cli if you're a Linux ninja, but that's above my skill set.

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

 

Maybe that's what I'm seeing at the moment all the access lights on my caddy's keep lighting up every second or so, very odd, used to just seeing just the blue power led's on not all the drives twinkling green access led's.

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

The "autorefreshing" isn't done in the traditional way of a complete reload of the page through emhttp. Instead an ajax query is done to read the current array values (the file '/var/local/emhttp/disks.ini) and update only the table part.

 

This doesn't constantly access the drives (observation of Harpz), though not sure what is causing this...

 

Quite some thought has gone into 'smart' updating (for example only the active page is updated to avoid a lot of background polling).

 

In my testing with running a parity check, there is very little extra delay.

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

 

Maybe that's what I'm seeing at the moment all the access lights on my caddy's keep lighting up every second or so, very odd, used to just seeing just the blue power led's on not all the drives twinkling green access led's.

 

If you move away from the main screen (e.g. go to "shares"), does the flickering stop ?

 

Btw there is an option to disable the dynamic updating (see settings -> user preferences -> display settings) and basically go back to the old manual refresh method.

 

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

 

It is not an absolute must do, actually the webGui plugin (and all optional plugins) install perfectly okay without doing a reboot, but not knowing what has been installed already and do it the *easy* way, it is the suggested way for the non-technical inclined people...

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

The "autorefreshing" isn't done in the traditional way of a complete reload of the page through emhttp. Instead an ajax query is done to read the current array values (the file '/var/local/emhttp/disks.ini) and update only the table part.

 

This doesn't constantly access the drives (observation of Harpz), though not sure what is causing this...

 

Quite some thought has gone into 'smart' updating (for example only the active page is updated to avoid a lot of background polling).

 

In my testing with running a parity check, there is very little extra delay.

 

I would suggest a test and rename smartctl temporarly on /usr/sbin.

If the temps stop getting updated in the .ini file, then smartctl is accessing the drives.

 

I would propose a configurable refresh value so people can see the status without interfering with the parity check.

Or some automated code that slows down the automatic refresh if a parity operation is in progress.

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

 

It is not an absolute must do, actually the webGui plugin (and all optional plugins) install perfectly okay without doing a reboot, but not knowing what has been installed already and do it the *easy* way, it is the suggested way for the non-technical inclined people...

 

One day, someone may write a tool to install the plugin from the browser.

I think the issue still would exist to remove that plugin while it has been loaded.

Other then that, people have the option to do the install from the command line.

 

While packages can be installed/uninstalled from the command line, plugins may require more effort to install apps with custom scripts.

 

What I loved about RPM is they have the install and uninstall block to make it easier.

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

The "autorefreshing" isn't done in the traditional way of a complete reload of the page through emhttp. Instead an ajax query is done to read the current array values (the file '/var/local/emhttp/disks.ini) and update only the table part.

 

This doesn't constantly access the drives (observation of Harpz), though not sure what is causing this...

 

Quite some thought has gone into 'smart' updating (for example only the active page is updated to avoid a lot of background polling).

 

In my testing with running a parity check, there is very little extra delay.

 

I would suggest a test and rename smartctl temporarly on /usr/sbin.

If the temps stop getting updated in the .ini file, then smartctl is accessing the drives.

 

I would propose a configurable refresh value so people can see the status without interfering with the parity check.

Or some automated code that slows down the automatic refresh if a parity operation is in progress.

So reading the .ini file triggers smartctl ?

I'll do a test as you suggest and let you know.

 

Actually the refresh time is changeable, but not directly from the GUI (display settings). Though you can completely disable the updating (it also brings back the 'old' refresh button - no really gone but made hidden).

 

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

 

It is not an absolute must do, actually the webGui plugin (and all optional plugins) install perfectly okay without doing a reboot, but not knowing what has been installed already and do it the *easy* way, it is the suggested way for the non-technical inclined people...

 

One day, someone may write a tool to install the plugin from the browser.

I think the issue still would exist to remove that plugin while it has been loaded.

Other then that, people have the option to do the install from the command line.

 

While packages can be installed/uninstalled from the command line, plugins may require more effort to install apps with custom scripts.

 

What I loved about RPM is they have the install and uninstall block to make it easier.

 

Slackware can do this too. Tarballs are the "native" package and they install and uninstall cleanly (and it's trivial to create them). They require no more effort than telnet, and they could be managed via a web interface too.

 

We have the technology now to do this in slackware, yet it's somehow been ignored by everyone. In trying to make plugins easier for "the non-technical user", they got really awkward and overcomplicated in the process.

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

 

It is not an absolute must do, actually the webGui plugin (and all optional plugins) install perfectly okay without doing a reboot, but not knowing what has been installed already and do it the *easy* way, it is the suggested way for the non-technical inclined people...

 

One day, someone may write a tool to install the plugin from the browser.

I think the issue still would exist to remove that plugin while it has been loaded.

Other then that, people have the option to do the install from the command line.

 

While packages can be installed/uninstalled from the command line, plugins may require more effort to install apps with custom scripts.

 

What I loved about RPM is they have the install and uninstall block to make it easier.

 

Slackware can do this too. Tarballs are the "native" package and they install and uninstall cleanly (and it's trivial to create them). They require no more effort than telnet, and they could be managed via a web interface too.

 

We have the technology now to do this in slackware, yet it's somehow been ignored by everyone. In trying to make plugins easier for "the non-technical user", they got really awkward and overcomplicated in the process.

 

 

I know slackware tarballs have the doinst functionality.

Do they have an uninstall function?

Share this post


Link to post
Share on other sites

keep in mind, if the status screen is autorefreshing to the browser, this could have the potential to slow down a parity operation.

Each refresh of the front page that calls emhttp and/or calls smartctl could trigger the drive heads to seek away from the operation it is doing. Just a heads up.

The "autorefreshing" isn't done in the traditional way of a complete reload of the page through emhttp. Instead an ajax query is done to read the current array values (the file '/var/local/emhttp/disks.ini) and update only the table part.

 

This doesn't constantly access the drives (observation of Harpz), though not sure what is causing this...

 

Quite some thought has gone into 'smart' updating (for example only the active page is updated to avoid a lot of background polling).

 

In my testing with running a parity check, there is very little extra delay.

 

I would suggest a test and rename smartctl temporarly on /usr/sbin.

If the temps stop getting updated in the .ini file, then smartctl is accessing the drives.

 

I would propose a configurable refresh value so people can see the status without interfering with the parity check.

Or some automated code that slows down the automatic refresh if a parity operation is in progress.

So reading the .ini file triggers smartctl ?

I'll do a test as you suggest and let you know.

 

Actually the refresh time is changeable, but not directly from the GUI (display settings). Though you can completely disable the updating (it also brings back the 'old' refresh button - no really gone but made hidden).

 

 

Reading the INI file does not trigger the smartctl.

However I'm not sure how those values get updated in the .ini file.

Somewhere along the line, emhttp has to update them and write them to disk.

Share this post


Link to post
Share on other sites

My tests below.

 

root@unRAID:/usr/sbin# ls -l /var/local/emhttp/disks.ini

-rw-rw-rw- 1 root root 1833 2013-12-23 17:59 /var/local/emhttp/disks.ini

 

root@unRAID:/usr/sbin# date

Mon Dec 23 18:26:21 EST 2013

 

refresh browser.

 

root@unRAID:/usr/sbin# ls -l /var/local/emhttp/disks.ini

-rw-rw-rw- 1 root root 1833 2013-12-23 18:26 /var/local/emhttp/disks.ini

 

root@unRAID:/usr/sbin# mv /usr/sbin/smartctl /usr/sbin/smartctl.bak

 

root@unRAID:/usr/sbin# ls -l /var/local/emhttp/disks.ini

-rw-rw-rw- 1 root root 1827 2013-12-23 18:27 /var/local/emhttp/disks.ini

 

root@unRAID:/usr/sbin# grep -i temp /var/local/emhttp/disks.ini

temp="*"

temp="*"

temp="*"

temp="*"

temp="*"

 

root@unRAID:/usr/sbin# mv /usr/sbin/smartctl.bak /usr/sbin/smartctl

 

refresh browser.

 

root@unRAID:/usr/sbin# grep -i temp /var/local/emhttp/disks.ini   

temp="26"

temp="27"

temp="29"

temp="*"

temp="*"

 

The point of my post is, auto refresh could have the potential to cause drive seeks. So observe this carefully during a parity check and/or slow down the autorefresh to some reasonable value if a parity operation is in progress.

Share this post


Link to post
Share on other sites

Is no one else incredibly bothered by the fact that plgs require a reboot? It's almost 2014. Why should I have to restart my machine for a plugin?

 

It is not an absolute must do, actually the webGui plugin (and all optional plugins) install perfectly okay without doing a reboot, but not knowing what has been installed already and do it the *easy* way, it is the suggested way for the non-technical inclined people...

 

One day, someone may write a tool to install the plugin from the browser.

I think the issue still would exist to remove that plugin while it has been loaded.

Other then that, people have the option to do the install from the command line.

 

While packages can be installed/uninstalled from the command line, plugins may require more effort to install apps with custom scripts.

 

What I loved about RPM is they have the install and uninstall block to make it easier.

 

Slackware can do this too. Tarballs are the "native" package and they install and uninstall cleanly (and it's trivial to create them). They require no more effort than telnet, and they could be managed via a web interface too.

 

We have the technology now to do this in slackware, yet it's somehow been ignored by everyone. In trying to make plugins easier for "the non-technical user", they got really awkward and overcomplicated in the process.

 

 

I know slackware tarballs have the doinst functionality.

Do they have an uninstall function?

 

Sure does: removepkg

 

(can't seem to link directly to it. Just scroll down a tad.)

Share this post


Link to post
Share on other sites

Reading the INI file does not trigger the smartctl.

However I'm not sure how those values get updated in the .ini file.

Somewhere along the line, emhttp has to update them and write them to disk.

 

I did a quick test by moving smartctl to another location, temp values are instantly gone. This suggests that the .ini file is frequently updated. It is something happening in the background, but unclear to me how it is done...

 

When all disks are spun-down and page updating continues (keep reading the .ini file), it won't cause any access to the disks.

 

Share this post


Link to post
Share on other sites

Reading the INI file does not trigger the smartctl.

However I'm not sure how those values get updated in the .ini file.

Somewhere along the line, emhttp has to update them and write them to disk.

 

I did a quick test by moving smartctl to another location, temp values are instantly gone. This suggests that the .ini file is frequently updated. It is something happening in the background, but unclear to me how it is done...

 

When all disks are spun-down and page updating continues (keep reading the .ini file), it won't cause any access to the disks.

 

When the front page or perhaps when some other page is updated via an emhttp call.

 

I would suggest monitoring the time and date on the .ini file as your autorefresh is occurring.

See how frequently the .ini file is getting updated.

 

I just did a test and did not access the front page, I accessed a totally unrelated page and saw it update.

I do not think it's all that big of a deal.

 

a smartctl -A (which is what Tom does) vs a smartctl -a seem to take a different amount of time.

Share this post


Link to post
Share on other sites

Reading the INI file does not trigger the smartctl.

However I'm not sure how those values get updated in the .ini file.

Somewhere along the line, emhttp has to update them and write them to disk.

 

I did a quick test by moving smartctl to another location, temp values are instantly gone. This suggests that the .ini file is frequently updated. It is something happening in the background, but unclear to me how it is done...

 

When all disks are spun-down and page updating continues (keep reading the .ini file), it won't cause any access to the disks.

 

Here's my test

 

while :; do date -r /var/local/emhttp/disks.ini; sleep 1; done

 

Mon Dec 23 17:44:58 CST 2013 <-- All disks spun down
Mon Dec 23 17:44:58 CST 2013 
Mon Dec 23 17:45:00 CST 2013 <-- Page refresh, all spun down
Mon Dec 23 17:45:00 CST 2013
Mon Dec 23 17:45:02 CST 2013 <-- Page refresh, all spun down
Mon Dec 23 17:45:02 CST 2013
Mon Dec 23 17:45:02 CST 2013
Mon Dec 23 17:45:05 CST 2013 <-- Spin up disks, file written every few seconds from here
Mon Dec 23 17:45:05 CST 2013 
Mon Dec 23 17:45:07 CST 2013
Mon Dec 23 17:45:08 CST 2013 
Mon Dec 23 17:45:08 CST 2013
Mon Dec 23 17:45:08 CST 2013
Mon Dec 23 17:45:11 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:12 CST 2013
Mon Dec 23 17:45:20 CST 2013
Mon Dec 23 17:45:20 CST 2013
Mon Dec 23 17:45:20 CST 2013
Mon Dec 23 17:45:23 CST 2013
Mon Dec 23 17:45:23 CST 2013
Mon Dec 23 17:45:25 CST 2013
Mon Dec 23 17:45:26 CST 2013
Mon Dec 23 17:45:26 CST 2013
Mon Dec 23 17:45:26 CST 2013
Mon Dec 23 17:45:29 CST 2013
Mon Dec 23 17:45:30 CST 2013
Mon Dec 23 17:45:30 CST 2013
Mon Dec 23 17:45:32 CST 2013
Mon Dec 23 17:45:32 CST 2013
Mon Dec 23 17:45:32 CST 2013
Mon Dec 23 17:45:35 CST 2013
Mon Dec 23 17:45:35 CST 2013
Mon Dec 23 17:45:35 CST 2013
Mon Dec 23 17:45:38 CST 2013
Mon Dec 23 17:45:38 CST 2013
Mon Dec 23 17:45:40 CST 2013
Mon Dec 23 17:45:41 CST 2013
Mon Dec 23 17:45:41 CST 2013
Mon Dec 23 17:45:41 CST 2013
Mon Dec 23 17:45:44 CST 2013
Mon Dec 23 17:45:45 CST 2013
Mon Dec 23 17:45:45 CST 2013
Mon Dec 23 17:45:47 CST 2013
Mon Dec 23 17:45:47 CST 2013
Mon Dec 23 17:45:47 CST 2013
Mon Dec 23 17:45:50 CST 2013

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.