bonienl Posted December 23, 2013 Share Posted December 23, 2013 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 Link to comment
AndroidCat Posted December 23, 2013 Share Posted December 23, 2013 Looks very nice and functional. Great work! Link to comment
Harpz Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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! Link to comment
Harpz Posted December 23, 2013 Share Posted December 23, 2013 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 Link to comment
nicinabox Posted December 23, 2013 Share Posted December 23, 2013 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? Link to comment
dirtysanchez Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
nicinabox Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
dirtysanchez Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
Harpz Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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. Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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. Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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... Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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). Link to comment
nicinabox Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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? Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
nicinabox Posted December 23, 2013 Share Posted December 23, 2013 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.) Link to comment
bonienl Posted December 23, 2013 Author Share Posted December 23, 2013 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. Link to comment
WeeboTech Posted December 23, 2013 Share Posted December 23, 2013 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. Link to comment
nicinabox Posted December 23, 2013 Share Posted December 23, 2013 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 Link to comment
Recommended Posts