2 hours ago, dlandon said:

UD was not formatting and partitioning XFS or BTRFS disks to start at sectors 63 or 64 as unRAID requires.

 

Yes that has been a longstanding issue with UD.  Prior to this release, we just accepted that for the cache disk/pool.  But with encryption it's too much of a pain to do that and so we insist on "unraid standard partition layout" for all array or cache devices.  This may prove to be a bigger issue when 6.4 'stable' is published so I need to think about this...

3 minutes ago, limetech said:

 

Yes that has been a longstanding issue with UD.  Prior to this release, we just accepted that for the cache disk/pool.  But with encryption it's too much of a pain to do that and so we insist on "unraid standard partition layout" for all array or cache devices.  This may prove to be a bigger issue when 6.4 'stable' is published so I need to think about this...

 

There's also a problem with NVMe devices, and I'm using a standard unRAID partition starting on sector 64, re-posting since this thread got busy:

 

 

5 minutes ago, limetech said:

 

Yes that has been a longstanding issue with UD.  Prior to this release, we just accepted that for the cache disk/pool.  But with encryption it's too much of a pain to do that and so we insist on "unraid standard partition layout" for all array or cache devices.  This may prove to be a bigger issue when 6.4 'stable' is published so I need to think about this...

UD has been updated so it should not be an issue going forward.

Also we are making a few tweaks in setting up http/https:

• Get rid of 'only' setting, you can pick for Use SSL/TLS: Yes|No|Auto
• If set to Yes, will also redirect all http -> https
• If set to No, will also redirect all https -> http
• If set to Auto, will behave same as Yes if /boot/config/ssl/certs/certificate_bundle.pem exists, else behave like No
• You can only Provision a Lets Encrypt cert if set to Auto

For those using self-signed certs, to switch to a LE cert, you would:

1. Set Use SSL/TLS to Auto (this will restore http)
2. Click Provision (this will generate cert and restore https)

If you want to use your own cert, you can create the file "certificate_bundle.pem" and upload to /boot/config/ssl/certs.  This pem file must consist of the concatenation of:

• The certificate
• The certificate intermediate chain (if necessary)
• The private key (note nginx is smart and knows not to send the private key to a client even if located in same pem file)

(Actually this functionality is already present in -rc8q)

2 minutes ago, johnnie.black said:

There's also a problem with NVMe devices, and I'm using a standard unRAID partition starting on sector 64, re-posting since this thread got busy:

 

Yeah we fixed that too in next -rc.

21 minutes ago, limetech said:

 

Yes that has been a longstanding issue with UD.  Prior to this release, we just accepted that for the cache disk/pool.  But with encryption it's too much of a pain to do that and so we insist on "unraid standard partition layout" for all array or cache devices.  This may prove to be a bigger issue when 6.4 'stable' is published so I need to think about this...

I can confirm backing up/upgrading/reformatting/restoring works to solve the issue.

27 minutes ago, limetech said:

This may prove to be a bigger issue when 6.4 'stable' is published so I need to think about this...

 

I don't think it's a problem as long as there's a warning on the release notes, using the cache yes and prefer options together with the mover it's easy to move all cache data to the array before upgrading, upgrade, re-format and restore.

3 minutes ago, johnnie.black said:

 

I don't think it's a problem as long as there's a warning on the release notes, using the cache yes and prefer options together with the mover it's easy to move all cache data to the array before upgrading, upgrade, re-format and restore.

It's only an issue if the disk was formatted and partitioned with UD.  Not sure it's that much of a problem.

Just now, dlandon said:

It's only an issue if the disk was formatted and partitioned with UD.  Not sure it's that much of a problem.

 

I'm sure there will be a few but it's easy to solve and as long as there's a warning I think it's enough.

Just now, johnnie.black said:

 

I'm sure there will be a few but it's easy to solve and as long as there's a warning I think it's enough.

Agreed.

Thanks for the (plex inspired?) https provisioning! This is truly amazing.

 

I am sure, you are updating the certificate automatically, before it becomes invalid. (are you?)

Also, does the hash, before unraid.net stay the same?

Edited September 3, 20178 yr by rix

1 minute ago, rix said:

Thanks for the (plex inspired?) https provisioning! This is truly amazing.

 

I am sure, you are updating the certificate automatically, before it becomes invalid. (are you?)

 

Agreed, really nice implementation of LE.  Hats off!

just fyi, when browsing around the ui I see the following log message:

Sep  3 16:31:01 husky php-fpm[6932]: [WARNING] [pool www] server reached max_children setting (10), consider raising it

 

win7 w/ firefox 55.0.3

40 minutes ago, rix said:

Thanks for the (plex inspired?) https provisioning! This is truly amazing.

 

I am sure, you are updating the certificate automatically, before it becomes invalid. (are you?)

Also, does the hash, before unraid.net stay the same?

 

Yes will renew but code not in yet, we have 59 more days to get it done

Yes hash will remain the same but is tied to your registration key file, so it will change if your key changes, e.g., Trial -> Basic/Plus/Pro or upgrade or replacement.

20 hours ago, limetech said:

 

If you click Help while on that page, go to the bottom are some instructions for common routers.  Let me know what you had to do and we'll add it to the Help.

Just went in there and tried again (no changes made to my network). Left on defaults (I think the trick was having it on Auto rather than Yes like when I tried and failed before). I am now on SSL. W00t!

 

Suggestion: maybe a note that Provisioning will restart services. May be obvious to most unRaiders but was certainly a surprise to my Plex users. LOL

Edited September 3, 20178 yr by interwebtech

This looks like an exciting release. Going to update as soon as my preclear has finished.

 

Question--how will this play with the LetsEncrypt docker container from LSIO? I'm currently using this Docker for reverse proxy, and I assume that I'm either going to need to change the HTTPS port on that container or on unRAID... 

22 minutes ago, kaiguy said:

This looks like an exciting release. Going to update as soon as my preclear has finished.

 

Question--how will this play with the LetsEncrypt docker container from LSIO? I'm currently using this Docker for reverse proxy, and I assume that I'm either going to need to change the HTTPS port on that container or on unRAID... 

 

I moved my dockers to their own bridge. Each docker has their own IP, so I don't have conflicts on ports.

I had configured my /config/go to this

 

/usr/local/sbin/emhttp -p 80 &        # starts nginx on port 80 (http)

I am now using the built-in LE SSL settings thru the GUI and set to "only" on 443.  Should I, and if so how, edit my go file so that I don't have a conflict?

 

Thanks!

Edited September 3, 20178 yr by smdion

I've been playing around with encryption on a test VM. This is a very nice implementation, completely transparent to use.

 

The setup:

• 2 cores of my Xeon E3-1240v3
• 2 gb of ram
• Disk1 is a 5gb vdisk (yeah, tiny)
• Cache is a 50gb vdisk
• No parity

On this system, there appears to be NO performance penalty for encryption. I copied a 1GB file from my laptop to the VM over a 1GB network connection, and it copied at a speed of 113 MB/s regardless of whether I copied it to the virtual cache drive or the encrypted virtual disk1 (both of which are on the same physical SSD). Basically, it looks like this processor will have no problems keeping up with encrypted writes over the network.

 

Again, once it is up and running it is completely transparent. But I did run into a few issues getting to that point:

• The initial setup is kind of a pain - on the disk page you choose an encrypted file system, then start the array, try to format but find out you can't, so you go to the encryption page to set a key, but find out you can't set the key until you stop the array so you go back and stop the array, then back and set the encryption key, then back to start the array, then format the disk. whew
  
  One way to simplify this would be to not let you choose an encrypted file system until you had set an encryption key. 
   
• When you are on the Main -> Array Operation tab and try to start the array without an encryption key, the page just reloads without any hints as to why the array didn't start. I think the Start button should be disabled, with a note and a link taking you over to the Encryption Settings page.
   
• The Encryption Settings page include a benchmark button, here are my results:

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1385173 iterations per second for 256-bit key
PBKDF2-sha256    1533005 iterations per second for 256-bit key
PBKDF2-sha512    1154819 iterations per second for 256-bit key
PBKDF2-ripemd160  974513 iterations per second for 256-bit key
PBKDF2-whirlpool  601938 iterations per second for 256-bit key

#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   128b   656.5 MiB/s  2854.4 MiB/s
    serpent-cbc   128b    82.6 MiB/s   555.9 MiB/s
    twofish-cbc   128b   181.7 MiB/s   352.5 MiB/s
        aes-cbc   256b   484.1 MiB/s  2176.4 MiB/s
    serpent-cbc   256b    85.7 MiB/s   555.9 MiB/s
    twofish-cbc   256b   181.5 MiB/s   352.8 MiB/s
        aes-xts   256b  2382.5 MiB/s  2382.1 MiB/s
    serpent-xts   256b   560.5 MiB/s   538.4 MiB/s
    twofish-xts   256b   340.5 MiB/s   348.0 MiB/s
        aes-xts   512b  1873.4 MiB/s  1880.1 MiB/s
    serpent-xts   512b   561.1 MiB/s   540.2 MiB/s
    twofish-xts   512b   343.1 MiB/s   348.4 MiB/s

Default PBKDF2 iteration time for LUKS: 2000 (ms)

Default compiled-in device cipher parameters:
 LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

What do these results show? There don't seem to be any choices to make based on this information, and I can't tell which of all these options is being used.

But mainly... this is an awesome release, unRAID just keeps getting better and better!

19 minutes ago, smdion said:

I had configured my /config/go to this

/usr/local/sbin/emhttp -p 80 &        # starts nginx on port 80 (http)

I am now using the built-in LE SSL settings thru the GUI and set to "only" on 443.  Should I, and if so how, edit my go file so that I don't have a conflict?

 

Thanks!

 

Per the OP, the ports are now managed in the GUI under Settings -> Identification -> SSL Cert Settings and any ports specified in the go script will be ignored. I deleted the ports from my go script to reduce confusion in the future, I have that line as simply:

/usr/local/sbin/emhttp &

 

Edited September 3, 20178 yr by ljm42

1 hour ago, interwebtech said:

Suggestion: maybe a note that Provisioning will restart services. May be obvious to most unRaiders but was certainly a surprise to my Plex users. LOL

 

Yes restarting all services is a pretty big hammer, I think we can make that smarter.

21 minutes ago, smdion said:

I am now using the built-in LE SSL settings thru the GUI and set to "only" on 443.  Should I, and if so how, edit my go file so that I don't have a conflict?

 

The options are still accepted by the 'emthtp' script invoked from your 'go' file, but they are totally ignored.  All port assignment is done via the Identification settings page.  Also, no input error checking is done on those fields in this release so be nice it will be hardened later.

11 minutes ago, ljm42 said:

I've been playing around with encryption on a test VM.

 

Right it's a little rough around the edges still.  The point of the benchmark is to aide in selecting a different cipher if you want to, though we don't provide a way for you to do that yet

 

If the array won't start because no keyfile it does say something like that in the footer of the webGui.  But yes better notification of this in order.  BTW the messages appearing in the footer are implemented using websockets as well as the cpu load info on the Dashboard.  Over time we hope to eliminate much if not all javascript browser-side polling and exclusively use websockets for updating real-time info.

Upgrade worked fine, now using https. Small surprise on the services restart (I should have known) but worked smoothly.

 

Still no NVME temps!
 

Cheers,

Just now, Lebowski said:

Still no NVME temps!

 

Fixed in next -rc.