unRAID Server Release 6.1-rc2 Available

[bonienl]

To make hidden shares more explicit, an asterisk symbol can be added, eg. public *

[itimpi]

To make hidden shares more explicit, an asterisk symbol can be added, eg. public *

That would work for me.

[squirrellydw]

woohoo dual parity.  question once that is implemented how many disks can you lose and still keep data?

[itimpi]

woohoo dual parity.  question once that is implemented how many disks can you lose and still keep data?

2.  That is why it is called dual parity!

[gundamguy]

Assumption about Dual Parity.

 

It'll reduce the number of array disks you can have by 1, if you implement it?

[itimpi]

Assumption about Dual Parity.

 

It'll reduce the number of array disks you can have by 1, if you implement it?

I am not sure that this has been confirmed, but I would not be surprised if that is the case.

 

One question I have regarding the use of dual parity is if an error is detected during a correcting parity check (without a disk failing) if the implementation will be able to detect which disk has the error and correcting that rather than simply changing the parity disk as the case in the current single parity implementation.  If so this is likely to reduce the chance of 'bitrot' of data.

[JonathanM]

woohoo dual parity.  question once that is implemented how many disks can you lose and still keep data?

The more exciting part is that this should allow data integrity checks without add on schemes. Instead of the current situation of just knowing that one of the disk set is corrupt when parity is out of sync, dual parity should allow us to pinpoint which disk caused the error, and fix it. Bit rot no more!

 

Hash values are still very useful for comparing files on different systems, and auditing back up accuracy, so bunker and bitrot type scripts still have their place.

[mr-hexen]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

[limetech]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

[limetech]

It would be useful if the Global Share Settings had another option of "Yes (hidden)" so that I did not have to change each disk share individually

I didn't do it like that because 'hidden' is SMB only concept.  If you set to "Yes (hidden)" there, it would not apply to AFP/NFS/FTP/etc.  I guess the option could be "Yes (hidden - SMB only)" but this adds complexity.

 

On closer examination of the Disk Shares page I can see that the security setting under the SMB column implies the visibility as it is in italic for hidden shares, and absent for shares that are not visible.  Maybe this needs to be a bit more explicit as it is easy to miss the subtle distinction between italic and normal fonts.

IMHO italics are fine.

[mr-hexen]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

 

lol oh SH!T. Now I'll be the target of the entire forum!!

 

Im sure you guys have discussed this at length internally, and potentially with MODS in a private sub-forum. Ultimately you  have to do whats best for Limetech and I want you too! The idea is to keep operating as a company so I can continue to receive support and upgrades (paid or not) for my system for the long term.

 

Call it 6.9 then, you know, because dual parity is a two part process

[Squid]

Call it 6.9 then, you know, because dual parity is a two part process

Don't think you can escape it that easily...  You're now the pariah of the forums

[bungee91]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

 

I have no issue of paying additional money for support and additional features, however (I personally (my opinion, calm down)) have no use for dual-parity, so would prefer not to pay additional if that is the main driver for the added cost.

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

lol oh SH!T. Now I'll be the target of the entire forum!!

 

Yes, you suck!

[Frank1940]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

 

Or make it a Pro only feature! 

 

In my opinion, dual parity is not really that necessary.  There have been very few times when two disks have failed at the same time or even during a rebuilt.  And I would bet that most of those were in systems where the sysop has not been watching things and performing periodic parity checks.  In those cases, dual parity would probably not prevented an issue because no action would be taken until after a third disk had failed.  The biggest advantage to dual parity is that the exact disk with the issue can be quickly determined provided there is only a single failure point. 

[peter_sm]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

tower-syslog-20150727-1836.zip

[sparklyballs]

What's coming in 6.2?  After 6.1 'stable' is released, the next significant feature for 6.2 will be double-parity protection using Reed-Solomon algorithm for second "parity" disk (a.k.a., "P+Q").  We plan on a brief closed beta and then a (hopefully) brief public beta.  This will be a true beta, meaning use on test server because data could be at risk - though not really because I always write bug-free code    More on this later....

 

HUGE news guys, great momentum happening with unRAID.

 

Thought, should this really be a 6.x point release? Why not 7.0 to help would be beta testers clearly know this is a completely new idea and beta.

 

We'll give that some thought, we can then make it a paid upgrade as well.

 

lol oh SH!T. Now I'll be the target of the entire forum!!

 

Im sure you guys have discussed this at length internally, and potentially with MODS in a private sub-forum. Ultimately you  have to do whats best for Limetech and I want you too! The idea is to keep operating as a company so I can continue to receive support and upgrades (paid or not) for my system for the long term.

 

Call it 6.9 then, you know, because dual parity is a two part process

 

mr-hexen, not mr-hexing

 

just saying....

[bonienl]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

[limetech]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

syslog attached

 

//Peter

 

It's not allowed anymore to pass an arbitrary command to execute like that.  What if a plugin, under certain circumstances, executed "/usr/bin/rm -r /mnt/user/*"?  Starting with -rc2 only commands/scripts in /usr/local/sbin can be invoked.  This is not an ideal solution either.  I'll open a topic on the Development board to discuss this. just discussing right in this topic, let's get 'er done.

[limetech]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

[peter_sm]

OK, I'm waiting for the solution ;-)

 

//Peter

[bonienl]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

 

The same restriction can be made here: only commands from /usr/local/sbin (at least that's what I would propose), but it will have impact on existing plugins.

 

[limetech]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

 

The same restriction can be made here: only commands from /usr/local/sbin (at least that's what I would propose), but it will have impact on existing plugins.

 

I was thinking to make it relative to $_SERVER['DOCUMENT_ROOT'] which is /usr/local/emhttp.

 

In openvpn case the 'openvpnserver script would be moved from /etc/rc.d to /usr/local/emhttp/plugins/openvpn/scripts and his form would like this:

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="plugins/openvpn/scripts/openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

[Squid]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

 

The same restriction can be made here: only commands from /usr/local/sbin (at least that's what I would propose), but it will have impact on existing plugins.

For my plugs (using openbox) there was the same issue.  All i did was move the scripts to /usr/local/sbin/pluginname/ and added in code to recognize what version of unraid i was running under since pre rc2 i had to use a full path, but rc2 i only could use the path within sbin

 

[limetech]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

 

The same restriction can be made here: only commands from /usr/local/sbin (at least that's what I would propose), but it will have impact on existing plugins.

For my plugs (using openbox) there was the same issue.  All i did was move the scripts to /usr/local/sbin/pluginname/ and added in code to recognize what version of unraid i was running under since pre rc2 i had to use a full path, but rc2 i only could use the path within sbin

 

Yeah I don't think it should be in /usr/local/sbin - just makes it one more thing to clean up for plugin remove.

[Squid]

Hi LT

 

I ahve this code in my plugin

 

<form name="stop_openvpnserver" method="POST" action="/update.htm" target="progressFrame">
          <input type="hidden" name="cmd" value="/etc/rc.d/rc.openvpnserver stop">
          <input type="submit" name="runCmd" value="Stop">
         </form>

 

and get this error in the syslog

emhttp: unsupported cmd:

when clicking  on the buttons

 

 

syslog attached

 

//Peter

 

emhttp can not execute arbitrary commands. You can adjust your code to the following:

<form name="stop_openvpnserver" method="POST" action="/update.php" target="progressFrame">
  <input type="hidden" name="#command" value="/etc/rc.d/rc.openvpnserver stop">
  <input type="submit" name="#apply" value="Stop">
</form>

 

Yes that will for for -rc2 but that's going to be next hole to plug.

 

The same restriction can be made here: only commands from /usr/local/sbin (at least that's what I would propose), but it will have impact on existing plugins.

For my plugs (using openbox) there was the same issue.  All i did was move the scripts to /usr/local/sbin/pluginname/ and added in code to recognize what version of unraid i was running under since pre rc2 i had to use a full path, but rc2 i only could use the path within sbin

 

Yeah I don't think it should be in /usr/local/sbin - just makes it one more thing to clean up for plugin remove.

Simplest solution at the time.

 

If it changes again, i will drop support for previous RC's and only support the current RC / stable release available.