Dynamix - V6 Plugins

[bonienl]

A new version 2016.09.15 of bleeding edge is available for download/upgrade.

 

Doesn't work on v6.2 stable, on purpose or mistake? 6.2 stable is not lower than rc5.

 

plugin: installing: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.bleeding.edge.plg
plugin: downloading https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.bleeding.edge.plg
plugin: downloading: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.bleeding.edge.plg ... done
plugin: installed unRAID version is too low, require at least version 6.2.0-rc5

 

No, this is as per design, see my original announcement.

 

Number of prerequisites before start using the latest and greatest...

 

1. You need to run unRAID v6.2.0-rc5. It will not install with any other version of unRAID

2. If you have installed the plugin dynamix.disk.io, this needs to be uninstalled before using this plugin

3. After installation it is recommended to reboot your server to get everything 'straightened'

 

I may release a 'new' version once I have verified correct operation with 6.2 stable.

 

[interwebtech]

SCSI Devices (unRAID 6.2 only) does not survive update to 6.2 stable

Plug-in disappears and disk are all unassigned again. I bet its the version check

[bonienl]

Plug-in disappears and disk are all unassigned again. I bet its the version check

 

You need to update the plugin (Dynamix SCSI Devices that is) afterwards your devices return 

[interwebtech]

Plug-in disappears and disk are all unassigned again. I bet its the version check

 

You need to update the plugin (Dynamix SCSI Devices that is) afterwards your devices return 

 

The plug-in was not listed when I looked. Checking now while on RC5

 

Updating them all before I try again. Thanks.

[bonienl]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

[Squid]

The loading of the webGUI hangs on the script "scan.php" which is started by the FCP plugin. The reason scan.php gets stuck is that it loads the PHP module DockerClient.php, which had a modification: instead of a hard-coded path reference it queries the web server to obtain the path information dynamically. This works well when pages are loaded thru the browser, but it doesn't when executed as a standalone script.

 

The solution: back to a hard-coded reference for this PHP module. Not my preference, but I don't want to oblige Squid to change his scripting method.

If you can come up with a way for me to still be able to access DockerClient via standalone scripts, then I'm ok with making necessary adjustments to both CA and FCP.  But, as it stands now, both of those plugins 100% require access to DockerClient via standalone scripts.  (and looked at CA and there is other scripts (beyond the backup script contained that would probably fail since its a php script of a bash script called via the webUI)

 

But, for me to redo those scripts as pure bash is pretty much not going to happen due to the complexities of recreating them in bash.

[interwebtech]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Thanks for speedy follow up. I am all good now.

[bonienl]

The loading of the webGUI hangs on the script "scan.php" which is started by the FCP plugin. The reason scan.php gets stuck is that it loads the PHP module DockerClient.php, which had a modification: instead of a hard-coded path reference it queries the web server to obtain the path information dynamically. This works well when pages are loaded thru the browser, but it doesn't when executed as a standalone script.

 

The solution: back to a hard-coded reference for this PHP module. Not my preference, but I don't want to oblige Squid to change his scripting method.

If you can come up with a way for me to still be able to access DockerClient via standalone scripts, then I'm ok with making necessary adjustments to both CA and FCP.  But, as it stands now, both of those plugins 100% require access to DockerClient via standalone scripts.  (and looked at CA and there is other scripts contained that would probably fail since its a php script of a bash script called via the webUI)

 

But, for me to redo those scripts as pure bash is pretty much not going to happen due to the complexities of recreating them in bash.

 

It is certainly not my intention to let you rewrite your scripts into bash (do a lot of PHP myself too).

 

I have changed scripts to query the webserver to get the root path which is then prepended to make a full path.

 

I haven't tried it yet, but a standalone script can set the variable which is normally done by the webserver. I.e.

 

$_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp";

 

DockerClient.php will read the above variable to construct the necessary paths.

 

If all of this doesn't work, last resort stays of course hard-coding...

 

[bonienl]

Thanks for speedy follow up. I am all good now.

 

Actually I had the same problem as you, so was more or less obliged to solve it

 

[Squid]

The loading of the webGUI hangs on the script "scan.php" which is started by the FCP plugin. The reason scan.php gets stuck is that it loads the PHP module DockerClient.php, which had a modification: instead of a hard-coded path reference it queries the web server to obtain the path information dynamically. This works well when pages are loaded thru the browser, but it doesn't when executed as a standalone script.

 

The solution: back to a hard-coded reference for this PHP module. Not my preference, but I don't want to oblige Squid to change his scripting method.

If you can come up with a way for me to still be able to access DockerClient via standalone scripts, then I'm ok with making necessary adjustments to both CA and FCP.  But, as it stands now, both of those plugins 100% require access to DockerClient via standalone scripts.  (and looked at CA and there is other scripts contained that would probably fail since its a php script of a bash script called via the webUI)

 

But, for me to redo those scripts as pure bash is pretty much not going to happen due to the complexities of recreating them in bash.

 

It is certainly not my intention to let you rewrite your scripts into bash (do a lot of PHP myself too).

 

I have changed scripts to query the webserver to get the root path which is then prepended to make a full path.

 

I haven't tried it yet, but a standalone script can set the variable which is normally done by the webserver. I.e.

 

$_SERVER['DOCUMENT_ROOT'] = "/usr/local/emhttp";

 

DockerClient.php will read the above variable to construct the necessary paths.

 

If all of this doesn't work, last resort stays of course hard-coding...

Well, since you've already hardcoded it back, you can try it out as I am unable to with your release. 

[ars92]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

 

 

 

[bonienl]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

[ars92]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

Hi

 

Its the webGUI plugin itself.

 

As can be seen below, there was an update yesterday which was pushed automatically(not sure if I chose auto update, or thats just the way it is) and before that I was happily using the webGUI for various operations. This morning, hen I went in to activate a VM,I was greeted with that error and have not been able to use the webGUI ever since. It responds to my clicks, but doesn't load properly. It seems to be trying to find files which are not supposed to be there, as if the dynamix made for 6.2 was somehow pushed to my 6.1.9 build (or something like that)

 

thanks

[bonienl]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

Hi

 

Its the webGUI plugin itself.

 

As can be seen below, there was an update yesterday which was pushed automatically(not sure if I chose auto update, or thats just the way it is) and before that I was happily using the webGUI for various operations. This morning, hen I went in to activate a VM,I was greeted with that error and have not been able to use the webGUI ever since. It responds to my clicks, but doesn't load properly. It seems to be trying to find files which are not supposed to be there, as if the dynamix made for 6.2 was somehow pushed to my 6.1.9 build (or something like that)

 

thanks

 

I responded to your other post on this as well.

 

- Delete the file /config/plugins/dynamix.plg on your flash and reboot

- There is no auto-update in stock unRAID, my guess is it was auto updated by CA, but the 6.2 GUI shouldn't have been available for 6.1.9 in the first place...

 

[ars92]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

Hi

 

Its the webGUI plugin itself.

 

As can be seen below, there was an update yesterday which was pushed automatically(not sure if I chose auto update, or thats just the way it is) and before that I was happily using the webGUI for various operations. This morning, hen I went in to activate a VM,I was greeted with that error and have not been able to use the webGUI ever since. It responds to my clicks, but doesn't load properly. It seems to be trying to find files which are not supposed to be there, as if the dynamix made for 6.2 was somehow pushed to my 6.1.9 build (or something like that)

 

thanks

 

I responded to your other post on this as well.

 

- Delete the file /config/plugins/dynamix.plg on your flash and reboot

- There is no auto-update in stock unRAID, my guess is it was auto updated by CA, but the 6.2 GUI shouldn't have been available for 6.1.9 in the first place...

 

Yep have responded on that thread, deleting the file fixed it. But wow, how the heck would an update for an external plugin update a plugin which is a crucial component of unraid itself....kinda scary

 

Just checked, seems to be dynamix was on auto update, although I seriously do not remember doing that! have reverted all auto updates to manual now.

 

Of all plugins, thats the one I would ensure would be on manual lol.

[bonienl]

Yes, need to do some research here, cause the updating shouldn't be possible (even with auto-update of CA on).

 

Manual update, is safest for the moment.

 

[Squid]

Yes, need to do some research here, cause the updating shouldn't be possible (even with auto-update of CA on).

 

Manual update, is safest for the moment.

I've also posted in the CA thread about this.  Pointless for me to update CA to disallow this, because most users would get the CA update via auto-updates at which point the UI will update also.

 

Easiest solution is to pull the update for dynamix

[Fireball3]

As there was an update for the s3sleep plugin lately, I did it.

Then I noticed, that my server didn't shut down last night and when checking the plugin status it was inactive.

Is it possible to keep/restore the pre-update status of a plugin when the update is complete?

Not sure what happened. All settings - including running state - are retained after a upgrade.

Yesterday another update of s3sleep was available.

I ran the update procedure and forgot to check the status of the service.

The server did not go to sleep last night - checked the s3sleep plugin status and it was stopped. 

New update, same problem.

But this time I remembered to start it manually 

 

I had checked the code before publishing the update and didn't find anything wrong. Can't say why yours doesn't do the auto restart

Just want to feed back.

For some reason the last 2 updates went flawless.

Meanwhile I got used to check the status after updating, but the service was always "started".

[southpaw5271]

I re-installed the plugin but now the options for my array are still missing. I cannot start my array and I need to! Can I start from SSH? How can I fix my Dynamix plugin?

[bonienl]

I re-installed the plugin but now the options for my array are still missing. I cannot start my array and I need to! Can I start from SSH? How can I fix my Dynamix plugin?

 

Sorry, which plugin?

[TODDLT]

I installed the Nerdpack to get PERL so I could use Dynamix System Temp.  I rebooted, but it still grays out the "detect" button uner the System Temp screen and says "Perl must be installed to do automated driver detection"

I noted PERL is in the list at the begining of the sticky for Nerdpack.  However it doesn't appear in the list under "Nerdpack" on the plugins tab.

 

See attached images and diagnostics file (just in case). My configuration below is current.

 

 

 

todd-svr-diagnostics-20160916-1622.zip

[Msan]

I installed the Nerdpack to get PERL so I could use Dynamix System Temp.  I rebooted, but it still grays out the "detect" button uner the System Temp screen and says "Perl must be installed to do automated driver detection"

I noted PERL is in the list at the begining of the sticky for Nerdpack.  However it doesn't appear in the list under "Nerdpack" on the plugins tab.

 

See attached images and diagnostics file (just in case). My configuration below is current.

 

Goto settings, nerdpack and install perl there..

[landS]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

Hi

 

Its the webGUI plugin itself.

 

As can be seen below, there was an update yesterday which was pushed automatically(not sure if I chose auto update, or thats just the way it is) and before that I was happily using the webGUI for various operations. This morning, hen I went in to activate a VM,I was greeted with that error and have not been able to use the webGUI ever since. It responds to my clicks, but doesn't load properly. It seems to be trying to find files which are not supposed to be there, as if the dynamix made for 6.2 was somehow pushed to my 6.1.9 build (or something like that)

 

thanks

 

I responded to your other post on this as well.

 

- Delete the file /config/plugins/dynamix.plg on your flash and reboot

- There is no auto-update in stock unRAID, my guess is it was auto updated by CA, but the 6.2 GUI shouldn't have been available for 6.1.9 in the first place...

 

Dang... same issue here.  Anyway to do this via SSH?  The Flash drive is not set as a share and the ability to physically remove the computer is very difficult (well above head level, lots of back twisting, very very limited maneuver room.

[bonienl]

Right, I needed some time to this after 6.2 stable became available. Latest version is 2016.09.15.

 

Corrected typo

 

Hi Bonienl,

 

Seems to be this specific update caused my 6.1.9 webGUI to be unusable, the PLG seems to be have been intended for 6.2 and not 6.1.9

 

Any ideas on how can I roll back?

 

Error: Warning: parse_ini_file(state/network.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/template.php on line 43 Warning: extract() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dynamix/template.php on line 43

 

Which plugin are you talking about?

 

The plugin Dynamix SCSI devices is/was for unRAID 6.2 only and shouldn't install on 6.1.9.

 

Hi

 

Its the webGUI plugin itself.

 

As can be seen below, there was an update yesterday which was pushed automatically(not sure if I chose auto update, or thats just the way it is) and before that I was happily using the webGUI for various operations. This morning, hen I went in to activate a VM,I was greeted with that error and have not been able to use the webGUI ever since. It responds to my clicks, but doesn't load properly. It seems to be trying to find files which are not supposed to be there, as if the dynamix made for 6.2 was somehow pushed to my 6.1.9 build (or something like that)

 

thanks

 

I responded to your other post on this as well.

 

- Delete the file /config/plugins/dynamix.plg on your flash and reboot

- There is no auto-update in stock unRAID, my guess is it was auto updated by CA, but the 6.2 GUI shouldn't have been available for 6.1.9 in the first place...

 

Dang... same issue here.  Anyway to do this via SSH?  The Flash drive is not set as a share and the ability to physically remove the computer is very difficult (well above head level, lots of back twisting, very very limited maneuver room.

 

Yes, telnet or SSH into your system and type

 

rm /boot/config/plugins/dynamix.plg

 

[landS]

That did the trick!  Fantastic   Many thanks!