Opawesome

Hi @doron Many thanks for your contribution. I am planning on testing your script (better do it before I need it). I have started reviewing the code and saw the following line: VALID_CHARS='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789~!@#$%^&*-=+ ' Yet, the cryptsetup gitlab (https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#1-general-questions) states that: Those printable characters are listed here: https://en.wikipedia.org/wiki/ASCII#Printable_characters Are there any reasons why you excluded some of them? Like the underscore for example? Best, OP

Hi @je82, I as wondering if you ever performed those tests you were mentioning a couple of months ago. Especially, can the software use the backed up LUKS header if the one on the disk were to become corrupt ? Best, OP

Oh, I see. Thanks !

https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions does not say, but some guy here says it's 512. But https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#1-general-questions does indicate that : Maybe that was your issue. Best, OP

Thanks. And which CPU ?

I have a Supermicro X11SSH-LN4-F with one LSI SAS 9201 16i. It has been working flawlessly for a year, with 10 HDDs attached to it. I bought it from this guy : https://www.ebay.fr/usr/ac-tech for 150,00 USD +shipping. The card does get quite hot, so I installed a fan installed in the PCI-E slot right below the card, with blowing air directly to on to the SAS card radiator. The bracket used to install the fan is like this one: https://www.amazon.com/Bracket-Three-Mount-Video-Cooling/dp/B00UJ9JSBY

Hi @ljm42, Thank you for your answer. I was unsure about this last chmod indeed. Have a good day. Best, OP

Il est possible que le fingerprint d'une des 2 machines ait changé avec la résolution des problèmes que tu as mentionnés. Dans ce cas les scripts contenant des connexions SSH automatiques ne fonctionnent plus jusqu'à ce que le nouveau fingerprint soit ajouté au fichier "known_hosts" de la machine client SSH. Cela se fait simplement en se connectant une fois manuellement avec une console.

I personally bought a LSI SAS 9201 16i for about 100 euros on eBay. You can add 16 SATA drives with it. No BIOS/firmware flashing required since it is just a HBA controller and not a RAID controller.

May I ask why you want to connect to SSH without password? Because there is always the possibility to login via RSA keys if you don't want to type passwords.

For what it's worth, I have a Supermicro X11SSH-LN4-F with one LSI SAS 9201 16i. It has been working flawlessly for a year. I had it connected to the PCI-E 3.0 x8 (in x16) slot first, but decided to move it to the 2nd PCI-E 3.0 x8 (in x8) slot afterwards, with a fan installed in the last PCI-E slot blowing air directly to on to the SAS card radiator. The bracket used to install the fan is like this one: https://www.amazon.com/Bracket-Three-Mount-Video-Cooling/dp/B00UJ9JSBY

Interesting. I wonder what would be the reason behind.

I believe there is indeed a chance to lose all your data if the LUKS header becomes corrupt, although I understand that the chance of that happening is lower with LUKS2 than with LUKS1. I am by no means an expert. I just have just been doing some reading / testing on the subject during a week or so. My understanding is that the LUKS headers only change if you perform an operation like changing the password, or add a new key. So based on that understanding, my guess would be that you only need to backup LUKS headers if and when you do perform such an operation. Anyway, as long as you keep your previous backups, I see no harm in scheduling a recurrent backup.

Hi @Lee Kim Tatt, Your problem was exactly as mine (freezing when jumping around the video), except that the problem occurred on 6.8.3 for me. Would you mind sharing your hardware configuration (MB, CPU, etc.) ? Best, OP

Hi all, First of all many thanks to @limetech for the continuous development of Unraid and for the new 6.9 version. I am now preparing to upgrade and want to modify my /config/go file in order to comply with new features such as the including of Intel i915 drivers or the changes made to the SSH configuration. Indeed, my attention was caught regarding the SSH improvements: https://wiki.unraid.net/Unraid_OS_6.9.0#SSH_Improvements , the following part in particular: Currently, my /config/go file is set up to allow unsupervised SSH connections to/from my remote backup server via RSA keys. I noticed that @Hoopster (whom I suspect might have the same kind of configuration) also noted that upgrading to Unraid 6.9 would require adjustments to the go file: https://forums.unraid.net/topic/103388-unraid-os-version-690-available/?do=findComment&comment=954138 My /config/go file is currently as follows: [...] # Copy RSA files to /root/.ssh folder and set permissions for files (not for Unraid 6.9+) # 1. Create .ssh folder for root mkdir -p /root/.ssh # 2. Copy private RSA key to localhost as id_rsa cp /boot/config/sshroot/server.key /root/.ssh/id_rsa # 3. Add authorized public RSA key to authorized_keys cat /boot/config/sshroot/client1.pub >> /root/.ssh/authorized_keys # 4. Add authorized public RSA key to authorized_keys cat /boot/config/sshroot/client2.pub >> /root/.ssh/authorized_keys # 5. Copy known_hosts to localhost to allow unsupervised connections cp /boot/config/sshroot/known_hosts /root/.ssh/known_hosts # 6. Apply correct permissions to .ssh folder's content chmod g-rwx,o-rwx -R /root/.ssh [...] My understanding is that I can simply remove all of the above from the /config/go file and just run once and for all the following commands before updating to Unraid 6.9: mkdir -p /boot/config/ssh/root cp /root/.ssh/id_rsa /boot/config/ssh/root cp /root/.ssh/authorized_keys /boot/config/ssh/root cp /root/.ssh/known_hosts /boot/config/ssh/root chmod g-rwx,o-rwx -R /boot/config/ssh/root Is that correct ? Many thanks, OP

Today, I found this tutorial by Mister @SpaceInvaderOne. This may be worth having a look @loopback. On paper, it seems to suit your needs :

+1

Hi @grunter This may interest you: https://www.anandtech.com/show/15863/the-intel-w480-motherboard-overview-lga1200-for-xeon-w-1200 They provide a review of several motherboards with a W-480 chipset: ASRock W480 Creator ASRock Rack W480D4U ASUS Pro WS W480-Ace DFI CMS310-W480 GIGABYTE W480 Vision D GIGABYTE W480 Vision W GIGABYTE W480M Vision W Supermicro X12SCZ-TLN4F Supermicro X12SCZ-F Supermicro X12SAE

Hi @kimifelipe Hi all Maybe I did not understand very well but, it does not seem safe to me to change the parity disk if you are already having problems with one data drive. Especially with only one parity disk and not knowing for sure that the issue is caused by the new data drive and not by something else like a cable, backplane, HBA adapter, or motherboard issue. What if you put back you old drive and it becomes corrupt because of a faulty hardware ? I guess you would be happy to not have removed your parity drive in such event. So unless I misunderstand the situation, I would recommend to: 1. check your cables and put the old data drive back in the array 2. check parity and make sure you have a valid parity 3. backup all your data (if not done already) 4. test the new data drive, outside of the array, with something like the preclear plugin and an advanced SMART test 5. if the tests are successful, then retry replacing the old data drive and rebuild the data from the parity 6. use your server and stress the new data drive for a couple of weeks to check that no new error occur on that data drive / slot (may seem unnecessary to many but I would personally do that if I only had only 1 parity drive) 7. when you are confident that the server is stable, upgrade the parity disk Best, OP

+1

That I don't understand. My understanding was that with LUKS : (i) the encryption/decryption is made at the kernel level, and that (ii) a device is created by LUKS resulting in software applications not even being aware that they are dealing with an encrypted partition.

Hi again @itimpi Many thanks for you detailed and insightful answer. I have though about the various issues/scenarios you mentioned and I have a few remarks: 1ST ISSUE: This sounds very logical. I didn't know you could make such a choice however. In this case, I understand that the only case where having or not having encryption enabled would make a difference is: (i) when the bad sector would be located in the LUKS; and (ii) Unraid fails to rebuild the corrupted data correctly. Assuming that LUKS headers are checked and within the scope of parity protection, then I guess such failure would immediately be noticed upon a reboot, because you would not be able to mount the LUKS partition and start the array. In that case, wouldn't you just have to restore your backed up LUKS headers on the incriminated data drive to fix the issue? Unless I am missing something of course. [As a side question (a bit off-topic): Also wouldn't having 2 parity disks help in the decision in determining which drive (parity1, parity2 or data) contains the incorrect data ? And if yes, does Unraid make that decision autonomously when checking/correcting parity ? I would be curious to know.] 2ND ISSUE: This case scenario sounds indeed quite bad. I imagine that maybe the 'hardware-caused" issue can be mitigated by using ECC memory. However, I don't really see how would disk encryption render data recovery more difficult. As long as the LUKS headers are intact (or able to be restored as mentioned above in 1st issue) and you can mount the LUKS partition after providing the decryption key, won't that partition by treated like a simple hard-drive device by the kernel, thus enabling you to use any data recovery tool you would have used anyway ? 3RD ISSUE: Same remark as for 2nd issue above. CONLUDING REMARKS I am by no mean an expert, so please be welcome to challenge my understanding above. I do understand that encryption adds a layer of potential problems but I would like to exactly understand the risk and I don't want to reject encryption if this additional layer of problems can be managed. In any event, I don't see any scenario where encryption could be a problem if you have full offsite backup. Does anyone see one aside forgetting password or losing key for both machines at the same time? Best, OP

Not saying that you should encrypt your data by any means, but when one has all its data backed up on a remote location, then the risk of loosing the locally encrypted data because of some sort of data corruption is, IMO, well mitigated.

Hmm. Scary. Wouldn't that be caught and fixed with a parity check ?

In case this helps, I made tests and improved an existing script which enables you to easily backup LUKS2 headers: @itimpi, I was considering switching to xfs-encrypted on my server. What exactly are you thinking about when you talk about "file system level corruption" ? Do you have in mind something other than a corruption in the fist 16MB sectors ? Best, OP