12 minutes ago, Helmonder said:

 

I know you know I'm joking right... Love your work !

 

weet ik

 

On 9/3/2017 at 0:18 AM, limetech said:

4Kn Device Support (-rc8q):

Yeah should work now.

Thanks, I'm looking forward to the final release. 

30 minutes ago, bonienl said:

weet ik

 

You made me google it.

1 hour ago, limetech said:

Basically this: for a server with encrypted storage, upon initial boot, you have to first go to Encryption Settings and enter your passphrase (or upload you keyfile).  We'll get rid of the "Retype passphrase" field.  Having done this, array should now Start.

 

Next, whenever you click the Format button, if one of the un-Mountable devices is configured for encryption, we'll generate an alert and have you type your passphrase again in order to continue.  (Exception: if you originally uploaded a keyfile instead of typing a passphrase, there will be no prompt.)  This satisfies both requirements: 1) in the normal start case you only type a passphrase once (no confusing confirmation box), and 2) when a new LUKS volume is created, we confirm the entered passphrase is what's intended.

 

Along these lines... when you boot the system your first inclination will be to go to Main -> Array Operation -> Start. We have already talked about adding text to that page that directs you back to Settings -> Encryption Settings before starting the array. But what if we just put the passphrase input box right next to the Start Array button?  (It should only show up if one of the disks is encrypted) Having everything in one place would be far more convenient.

19 hours ago, Lev said:

 

 

@local.bin 

 

that's a rather trolling way to phrase things. Can you better rephrase your question... who specific are the 'we' and when did 'we' ever say or imply such things? Unless you can better qualify your implied conclusion, the intent behind it are reasonable questionable.

 

Lol, me trolling, 'implied conclusion', 'the intent behind it are reasonable questionable' is that even English?

 

For some time now it has been stated in these forums that the Unraid admin gui shouldn't be exposed to the internet. Its not meant too be and it shouldn't be.

 

So I am merely asking if it now is safe to do so; Is that the 'implied conclusion' that you are looking for?

 

Thanks @Helmonder, so based on the https certs with LE needing to be seen by LE on the internet to validate, is it meant that we create the LE cert and disable the connection to the internet afterwards, as I thought they needed to remain online to keep validated.

 

I would love https on the gui with LE, but I'm not sure I want to leave it like that 

 

 

Edited September 7, 20178 yr by local.bin

5 minutes ago, local.bin said:

So I am merely asking if it now is safe to do so. Is that the 'implied conclusion' that you are looking for?

 

The use of the LE SSL cert as we have provided for at present does not provide for secure remote access to the webGui, just secure local access.  This means you should be able to enter passwords/encryption phrases, etc, from a browser on a PC on your local LAN to a server also on your local LAN without worrying about someone sniffing the LAN traffic.  You also get a nice green (or grey for Edge) lock icon in your address bar and don't have to accept a self-signed certificate.

1 minute ago, limetech said:

 

The use of the LE SSL cert as we have provided for at present does not provide for secure remote access to the webGui, just secure local access.  This means you should be able to enter passwords/encryption phrases, etc, from a browser on a PC on your local LAN to a server also on your local LAN without worrying about someone sniffing the LAN traffic.  You also get a nice green (or grey for Edge) lock icon in your address bar and don't have to accept a self-signed certificate.

 

Ok thats cool, thanks.

 

When using the LE services for my dockers they needed a FQDN to work and when you used a local IP address they would of course complain as the certs were created for the specific FQDN and not the IP address.

 

So it seems you have utilised LE locally, which I didn't realise was even possible, so thanks for the clarification.

 

Quote

Cool release, nice job.

 

 

 

Just now, local.bin said:

So it seems you have utilised LE locally, which I didn't realise was even possible, so thanks for the clarification.

 

 

No, what we do is generate a 640-bit "hash" that uniquely identifies your server.  We then use the LE api to provision a certificate with Common Name:

<hash>.unraid.net

Since we own the unraid.net domain all these certs reference a FQDN which is actually a subdomain of unraid.net.

Next we created a DNS server that resolves your unique FQDN to a local IP address, which was given at the time the cert was provisioned.  Since the IP address being returned is in one of the "private" IP address ranges, DNS rebinding protection can kick in if enabled.  Also if your local IP address changes, the FQDN will no longer resolve, which is why we recommend using a local static IP.  But if your IP does change you can delete file 'config/ssl/certs/certificate_bundle.pem' and click Provision again.  In this case you'll get the same SSL cert but we'll also update our DNS server with your new IP address in the process (but note it might take up to 60 sec for the DNS caches to invalidate).  Alternately you can create an entry in your PC's hosts file that directly resolves <hash>.unraid.net to your local IP address.

 

2 minutes ago, limetech said:

 

No, what we do is generate a 640-bit "hash" that uniquely identifies your server.  We then use the LE api to provision a certificate with Common Name:

<hash>.unraid.net

Since we own the unraid.net domain all these certs reference a FQDN which is actually a subdomain of unraid.net.

Next we created a DNS server that resolves your unique FQDN to a local IP address, which was given at the time the cert was provisioned.  Since the IP address being returned is in one of the "private" IP address ranges, DNS rebinding protection can kick in if enabled.  Also if your local IP address changes, the FQDN will no longer resolve, which is why we recommend using a local static IP.  But if your IP does change you can delete file 'config/ssl/certs/certificate_bundle.pem' and click Provision again.  In this case you'll get the same SSL cert but we'll also update our DNS server with your new IP address in the process (but note it might take up to 60 sec for the DNS caches to invalidate).  Alternately you can create an entry in your PC's hosts file that directly resolves <hash>.unraid.net to your local IP address.

 

 

Ok thanks for the detailed explanation.

 

So in theory (appreciating its a 640-bit hash) could my Unraid be accessed from the web with <hash>.unraid.net?

6 minutes ago, local.bin said:

So in theory (appreciating its a 640-bit hash) could my Unraid be accessed from the web with <hash>.unraid.net?

 

No because the IP address resolves to a local LAN IP.  You can try it.  Go here and enter your FQDN:

https://toolbox.googleapps.com/apps/dig/

 

If you try to access your FQDN from outside your network, it wont' resolve, or if it did happen to resolve, then whatever device it resolves to won't be your server.

45 minutes ago, local.bin said:

 

Lol, me trolling, 'implied conclusion', 'the intent behind it are reasonable questionable' is that even English?

 

For some time now it has been stated in these forums that the Unraid admin gui shouldn't be exposed to the internet. Its not meant too be and it shouldn't be.

 

So I am merely asking if it now is safe to do so; Is that the 'implied conclusion' that you are looking for?

 

Thanks @Helmonder, so based on the https certs with LE needing to be seen by LE on the internet to validate, is it meant that we create the LE cert and disable the connection to the internet afterwards, as I thought they needed to remain online to keep validated.

 

I would love https on the gui with LE, but I'm not sure I want to leave it like that 

 

 

 

Good that you ask because this is a major misconception.... There is no need to make sure unraid cannot access the internet, you want to avoid the internet getting to your server !

 

So getting the certificate is no problem, thats unraid talking to the internet.. When we say "do not expose unraid to the internet" that basically means "do not make unraid reachable from the internet, eg: do not change your router to make the webgui or telnet reachable..

8 minutes ago, Helmonder said:

There is no need to make sure unraid cannot access the internet,

 

Right.  It already has to do this for lots of things already:

• Validate Trials
• Check for OS updates
• Check for plugin updates
• Send notifications
• probably a few more things

Of course with Basic/Plus/Pro it will run just fine without any internet access too, except to correctly resolve your local FQDN for purpose of setting up https connections, it will require access to unraid.net DNS server, or you have to make an explicit entry for it in your PC's hosts file.  One other thing: LE wants people to use a feature called OCSP stapling.  This cuts down on the traffic from your browser to LE name servers used to validate the certificate.  We do enable this feature in unRAID nginx.  Not sure, but I think if server can't reach LE name servers it will still work...

 

Edit: struck out text is wrong because it's your Browser, not the server referencing unraid.net DNS.

4 hours ago, limetech said:

Thank you for the feedback!

 

 

We're very much open to suggestions for symbol/color, is there any kind of 'defacto standard' for this?  Something to bear in mind is that both differences in color and shape are generally required to indicate different states.  This is to accommodate people who have difficulty differentiating between colors.  For example if we used a green lock symbol to mean "ok" and same symbol but red to indicate "problem" some people would not be able to tell the difference.

 

 

As you point out, using color is not a good way of conveying information because of people with visual disabilities. I believe the standard for encryption is to use a padlock icon if the device is encrypted and locked. An unlocked padlock or a padlock unlocked with keys in it are commonly used to denote an encrypted drive that is now accessible and "decrypted". The status of the drive is entirely separate, but could be dealt with using a circle with an x so red/green color blind people can still interpret the page properly.

 

P.S. Thx for adding 4kn support in this release!

26 minutes ago, limetech said:

 

No because the IP address resolves to a local LAN IP.  You can try it.  Go here and enter your FQDN:

https://toolbox.googleapps.com/apps/dig/

 

If you try to access your FQDN from outside your network, it wont' resolve, or if it did happen to resolve, then whatever device it resolves to won't be your server.

 

Ok thanks, I will give it a try.

 

23 minutes ago, Helmonder said:

 

Good that you ask because this is a major misconception.... There is no need to make sure unraid cannot access the internet, you want to avoid the internet getting to your server !

 

So getting the certificate is no problem, thats unraid talking to the internet.. When we say "do not expose unraid to the internet" that basically means "do not make unraid reachable from the internet, eg: do not change your router to make the webgui or telnet reachable..

 

Exactly! Thanks. At first look it looked like LE was to access the GUI from the internet, but I now appreciate better what has been done.

 

Thanks both for the explanations. 

4 hours ago, limetech said:

Basically this: for a server with encrypted storage, upon initial boot, you have to first go to Encryption Settings and enter your passphrase (or upload you keyfile).  We'll get rid of the "Retype passphrase" field.  Having done this, array should now Start.

 

Next, whenever you click the Format button, if one of the un-Mountable devices is configured for encryption, we'll generate an alert and have you type your passphrase again in order to continue.  (Exception: if you originally uploaded a keyfile instead of typing a passphrase, there will be no prompt.)  This satisfies both requirements: 1) in the normal start case you only type a passphrase once (no confusing confirmation box), and 2) when a new LUKS volume is created, we confirm the entered passphrase is what's intended.

 

 

Sounds good to me. 

 

Another question: I assume that parity is calculated over the physical disks. Why then can't the array start with some disks still locked? Non-encrypted disks would still be usable. I assume, that this would solve Helmonder's issue (of course nobody would complain about the capability to have two arrays ).

Edit: probably not a good idea, shares that become dynamically available or go away would significantly increase complexity.

 

And another one: I assume that each disk has its own key, but they all share the same passphrase, correct? It might be helpful to add a backup of the LUKS headers to the config backup. Of course this would then be a suggestion for the maintainer of the plugin doing the config backup.

Edited September 7, 20178 yr by tstor

Is it possible that when HTTPS only access is enabled, you have nginx redirect http to https?

2 hours ago, tstor said:

I assume that parity is calculated over the physical disks.

Correct.

 

2 hours ago, tstor said:

Why then can't the array start with some disks still locked? Non-encrypted disks would still be usable.

Yes that is something we will permit in future releases.

 

2 hours ago, tstor said:

I assume that each disk has its own key, but they all share the same passphrase, correct? It might be helpful to add a backup of the LUKS headers to the config backup.

Yes, the way LUKS works is each disk has it's own master key, but the master key itself is "unlocked" (decrypted) with a unique passphrase.  Adding backup of LUKS headers is another feature to be added in a future release, as is ability to "unlock" a device which has a different passphrase than all the other devices.

 

1 hour ago, Dephcon said:

Is it possible that when HTTPS only access is enabled, you have nginx redirect http to https?

 

It already does this.

On 03/09/2017 at 0:31 PM, peter_sm said:

All my UEFI based VM will not start. The Seabios VM is OK.

I'm back on rc7a

//Peter

I have now a solution for this issue. My UEFI based VM's boots now. I was testing to go for the latest and greatest OVMF firmware and boom, it's boots just fine  now.

 

//Peter

Possible GUI issue:

 

I just finished a parity rebuild of a drive that failed. The process has finished and completed. 

 

The disk now also is green in Main/Array Devices.

 

Under "array operation" however "started" still shows an orange triangle. Als the STOP button still is greyed out because "parity operation is running", it is not.

 

 

Seems to be ok now... This took like 5/10 minutes though.. Seems like the GUI is not getting notified quickly enough..

50 minutes ago, Helmonder said:

Seems to be ok now... This took like 5/10 minutes though.. Seems like the GUI is not getting notified quickly enough..

 

This is by design. Once a parity operation is finished (100%) you will see the end result. You can click on the "Done" button to acknowledge and refresh the page.

OW.. missed that, sorry !

One thing I just noticed that I don't see in the change log is being able to do a read check on data drives when no parity drive is present.

3 minutes ago, jbartlett said:

One thing I just noticed that I don't see in the change log is being able to do a read check on data drives when no parity drive is present.

 

It's been like that since the v6.2-betas